Moduli: Fail2Ban automaattinen asennus ja konfigurointi

Ideani kurssin loppumoduliksi oli toteuttaa Salt-tila, joka asentaa ja konfiguroi Fail2Ban-ohjelman automaattisesti. Konfiguraatiota voisi myös helposti muokkailla pillar-itemien kautta. Fail2Ban ei entuudestaan ollut kovin tuttu, vaikka olinkin sitä ainakin yhdessä aiemmassa tehtävässä käyttänyt.

Koko projektin löydät GitHubistani.

Aion tässä blogipostauksessa hieman avata miten Salt-tilani toimii, sekä esitellä testaukseni tulokset.

Tärkein osa, eli itse tilatiedosto sisältöineen:

fail2ban:
  pkg.installed

/etc/fail2ban/jail.local:
  file.managed:
    - source: salt://ban_conf/jail.local
    - template: jinja
    - context:
      bantime: {{ pillar.get('bantime', '3600') }}
      findtime: {{ pillar.get('findtime', '600') }}
      maxretry: {{ pillar.get('maxretry', '5') }}
      email: {{ pillar.get('email', 'root@localhost') }}

fail2ban_service:
  service.running:
    - name: fail2ban
    - watch:
    - file: /etc/fail2ban/jail.local

Ensiksi Salt asentaa Fail2Ban-ohjelman jos sitä ei ole olemassa. Tämän jälkeen se alkaa hallita /etc/fail2ban/jail.local -tiedostoa (Fail2Ban asetukset sisältävä tiedosto) omasta kansiosta (srv/salt/ban_conf/jail.local) löytyvällä versiollaan. Tässä on myös määritelty erilaisia muuttujia, jotka löytyvät pillar-kansiosta, sekä annettu default-arvo siltä varalta jos pillar-kansion muuttujiin ei päästäkään käsiksi. Viimeiseksi Salt resetoi fail2ban-servicen jos jail.localiin tehdään muutoksia.

Salt-tilan ajamiseen käytin seuraavaa käskyä (salt-call –localin ansiosta tämä tila ei tarvitse Salt-Masteria toimiakseen):

sudo salt-call --local state.highstate --file-root srv/salt/ --pillar-root srv/pillar/

Tallensin myös kyseisen komennon omaksi skriptikseen (suola.sh).

Väsäsin myös Tero Karvisen sirotinta hyödyntäen asennusskriptin, joka asentaisi Salt-Minionin, Gitin ja tilani yhdellä kertaa. Skriptiä pääsee tarkastelemaan täältä.

Modulin testailua

Testasin modulia kahdella eri tapaa:

a) Täysin puhtaalla Xubuntu 16.04:lla (livetikun kautta), tällä oli tarkoitus varmistaa että jokaisen palikan asennus onnistuu ja asetustiedostoon tulee halutut muutokset.

b) Virtuaalipalvelimella varmistaakseni, että bannivasara tosiaan heiluisi oikeaan tahtiin.

a) Livetikku

livetikku1

Haetaan install.sh ja suoritetaan se.

livetikku2

Vasemmalla puolella skriptin loppuosa, oikealla puolella /etc/fail2ban/jail.local install.sh:n suorittamisen jäljiltä. Muutokset tulivat täysin oikein Salt-tilan kautta. Varmistetaan vielä lokitiedostoista:

less /var/log/fail2ban.log

livetikku3
Hyvältä näyttää! Sitten virtuaalipalvelimella testailua.

b) Virtuaalipalvelin

Kirjauduin sisään ja syötin seuraavat komennot:

git clone https://github.com/banaanivohveli/fail2ban.git
cd fail2ban
bash suola.sh

Tällä kertaa en halunnut ajaa koko install.sh:ta, koska palvelimeltani löytyi jo Git ja Salt. Asennus kuitenkin näytti menevän mutkattomasti loppuun asti ja nyt olikin testailun vuoro. Kirjauduin palvelimelta ulos ja syötin tarkoituksella väärää tunnusta ja salasanaa SSH:n kautta.

ssh vaara@foliohattu.me
-> salasanaksi vain näppäimistön rämpyttelyä

attempt1

Seuraavan puolen tunnin ajan (tilassani määrittelemä aika) SSH-yhteys tarjosi tuota Connection refused -ilmoitusta.

Kun vihdoin pääsin takaisin kirjautumaan palvelimelleni, kokeilin vielä vaihtaa bantimen 1800 sekunnista 180 sekuntiin.

Vaihdoin bantime.sls -pillarista tuon valuen ja ajoin suola.sh -skriptin uudelleen.

attempt2

Tarkastetaan vielä /var/log/fail2ban.log:

loki_4

Ok! Sitten taas uloskirjautuminen ja loginin väärinrämpyttely.

3 minuuttia myöhemmin pääsin tarkkailemaan lokeja:

less /var/log/auth.log

loki_3

Invalid user vaara, eli juurikin se mitä käytin. Nappasin IP:n talteen ja menin tutkimaan Fail2Banin omia lokejaan.

cat /var/log/fail2ban.log|grep 88.113.46.16

loki_2

Kello 12:13:01 fail2ban on ensimmäisen kerran saanut tiedon yrityksestäni kirjautua, huomatkaa että kellonaika täsmää auth.logista löytyvän tiedon kanssa. Nämä “Found” ilmoitukset ovat selvästi kirjautumisyrityksiä. Fail2Banin asetuksissa oleva “maxretry” (yksi pillar-itemeistäni) on sallittu määrä virheellisiä yrityksiä ennen kuin IP joutuu banniin. Olin sen määritellyt neljään ja näitä Found-rivejä on tosiaan neljä kappaletta, minkä jälkeen jouduinkin banniin. Lokista huomataan myös, että tasan kolme minuuttia myöhemmin IP-osoitteeni poistetaan bannista (viimeinen rivi). Eli juuri aiemmin määrittelemäni aika.

Näiden testien perusteella uskaltaisin väittää, että tilani toimii kuin sen halusinkin toimivan.

Parannettavaa?

Aiemmassa tehtävässä jo hieman pohdin tätä, mutta olisi hienoa jos käyttäjältä voitaisiin kysyä arvot kaikkiin pillar-itemeihin (bantimet, maxretryt yms.) install.sh-skriptiä ajettaessa. Näin ollen mihinkään Saltin tiedostoon ei tarvitsisi koskea.

Tästä voisi myös käydä koko jail.local-tiedoston läpi ja tehdä jokaiselle asetukselle oman Salt-muuttujan.

 

 

Toni Hukka
13.5.2018

Lähteet

Tero Karvisen Salt-ohjeita http://terokarvinen.com/?s=salt
Tero Karvinen – Sirotin https://github.com/terokarvinen/sirotin
Digital Ocean’s Fail2Ban guide https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-ubuntu-14-04

Advertisements

H6: Ensimmäinen versio modulista

a) Ensimmäinen versio, joka toimii optimiolosuhteissa.

Koko (tätä kirjoittaessa keskeneräinen) moduli löytyy GitHub-sivultani. Ensimmäinen versioni onkin jo ihan ookoolla mallilla ja sen pitäisikin jo jokseenkin toimia ajamalla suola.sh -skripti. Perusideana on, että pillareihin tulee erilaisia muuttujia, kuten banniajan pituus, mihin sähköpostiosoitteeseen lähetetään raportit bannatuista ip-osotteista yms.  Salt/ban_conf/ -kansiosta löytyy itse tila, sekä asetustiedosto, joka tähtää /etc/fail2ban/jail.conf -tiedostoon. Pillarin muuttujien kautta pystyisi helposti muuttamaan asetukset haluamakseen, eikä näin ollen konfigurointia tarvitsisi tehdä lähes ollenkaan (sekä ne sisältäisivät hyvät default-arvot).

Tällä hetkellä koko jutun suorittaminen vaatii, että Salt löytyy jo asennettuna koneesta, mutta lopullisessa versiossa tuokin sisältyisi asennuspakettiin.

b) Kokeile modulia tyhjässä koneessa.

Kokeilin moduliani Xubuntu 16.04 -livetikulla. Fail2ban asentui mukisematta ja kaksi testimuuttujaani löysivät tiensä asetustiedostoon, sekä fail2ban-service käynnistyi onnistuneesti uudelleen. En touhutessani tajunnut ottaa yhtäkään screenshottia tätä tehtävää varten, mutta sisällytän ne tulevaan loppuraporttiini.

Asetusten toimivuutta en päässyt testaamaan livetikun luonteesta johtuen, mutta lopulliseen versioon minun olisi tarkoitus kokeilla tämän tilan toimivuutta omalla virtuaalipalvelimellani – siis hankkimalla itselleni bannit omalle palvelimelleni. Sähköpostipalvelun toimivuus Fail2Banissa tarvitsee käsittääkseni jonkinlaisen MTA-ohjelman kylkeensä, joten on mahdollista että tämä jää kokeilematta. Jää nähtäväksi!

c) User story: ketkä ovat modulisi käyttäjät? Mitä he haluavat saada aikaan modulillasi? Missä tilanteessa he sitä käyttävät? Mitkä ovat tärkeimmät parannukset käyttäjän kannalta, joita moduliin pitäisi vielä tehdä? 

Modulini loppukäyttäjiä voisivat olla esim. aloittelevat virtuaalipalvelimen ylläpitäjät tai kuka tahansa, joka haluaa bannata tunkeilevia IP-osotteita. Ideaalitilanteessa modulini asentuisi hyvillä oletusasetuksilla yhden skriptin ajamisella.

Tärkeimmät parannukset ovat lisätä Saltin asennus ajettavaan skriptiin ja lisätä pillar-itemien määrää. Olisi erittäin hienoa jos käyttäjältä saisi jotenkin promptilla kysyttyä noiden pillar-itemien arvoja, mutta tämä voi mennä osaamisalueeni ulkopuolelle. Sekä toki kaikista tärkein parannus on varmistaa vielä, että tämä koko moduli ylipäätään toimii. 🙂

Tehtävänannot Tero Karvisen kurssisivulta.

H4: Muuttujia pilarista

Tehtävänannot kopioitu Tero Karvisen Palvelinten hallinta -kurssisivulta.

b) Tee kahdella orjalla esimerkki, jossa orjat saavat eri muuttujan pilarista. Tarkista ‘pillars.items’, että kummalekin orjalle mene eri tieto. Tee jokin muu kuin tunnilla tehty sshd-esimerkki.

Pohdiskelin, että mikä voisi olla semmoinen ohjelman asetustiedosto jota olisi näppärä muuttaa. Mieleeni tuli aiemmin Linux-kurssilla käytetty sysstat ja sen sar-komennon enablointia varten käytetty /etc/default/sysstat-tiedosto. Päätin siis tehdä niin, että toinen koneista saisi arvoksi “false” (komento ei käytössä) ja toinen “true” (komento käytössä).

Elikkäs aloitetaan kansion ja tiedoston luonnilla:

cd /srv/salt/
sudo mkdir statti
cd statti/
sudoedit init.sls

Ensiksi halusin kokeilla, että tila asentaa sysstatin jos sitä ei ole.

Init.sls sisällöksi tuli siis:

sysstat:
  pkg.installed

Testausta:

state_ajo.PNG

Molemmille koneille olikin jo asennettuna sysstat. Varmistin vielä poistamalla sysstatin ja ajamalla tilan uudelleen – asennus onnistui molemmille ongelmitta.

sysstat_asennus.PNG

Seuraavaksi kopioin sysstatin asetustiedoston luomaani salt-kansioon ja lisäsin init-tiedostoon, että tila tarkkailisi asetusmuutoksia kopioidusta tiedostosta.

sudo cp /etc/default/sysstat . (kopiointi kansioon)
sudo mv sysstat sysstat.txt (vaihdoin nimeä selkeyttääkseni asioita itselleni)
sudoedit sysstat.txt
Vaihdoin tähän tiedostoon manuaalisesti false --> true, tallennus ja poistuminen.

Init-tiedoston uudet muokkaukset:

sysstat:
  pkg.installed

/etc/default/sysstat:
  file.managed:
    - source: salt://statti/sysstat.txt

sysstat.service:
  service.running:
    - watch:
    - file: /etc/default/sysstat

Testataan ajamalla tila:

sudo salt '*' state.apply statti

state_toimii_vaihto.PNG

Kuvassa vain toisen koneen muutokset, mutta molemmille meni muutos läpi. Yritän hieman säästää tilaa tekemällä screenshoteista pienempiä. 🙂

Seuraavaksi vuorossa olisi pillarin hyödyntäminen. Aiempaan init-tiedostoon pitäisi tehdä taas pieniä viilauksia:

(alku ja loppuosuus täysin sama kuin aiemmassa kohdassa, boldilla muutokset)

/etc/default/sysstat:
  file.managed:
    - source: salt://statti/sysstat.txt
    - template: jinja
    - context:
      value: {{ pillar['value'] }}

Init osaa nyt katsoa pillar-kansiosta arvon. Vielä täytyisi lisätä {{ value }} sysstat.txt-tiedostoon, sekä käydä luomassa arvot sisältävät tiedostot pillar-kansioon. Ei muuta kuin töpinäksi:

sudoedit sysstat.txt
lisätään {{ value }} haluttuun kohtaan

value.PNG

Pillariin muutokset:

cd ../../pillar
sudoedit minttusar.sls
  -> sisältö: value: "true"
sudoedit vptoni.sls
  -> sisältö: value: "false"

pillar_items.PNG

Lisätään uudet tiedostot top.sls-tiedostoon:

sudoedit top.sls

toppi.PNG

Nyt kaiken oikeastaan pitäisikin toimia! Voidaan ajaa tila:

sudo salt '*' state.apply statti

true_väärä.PNG

false_väärä.PNG

Muutokset menivät läpi, mutta molempien arvot tulivat isolla alkukirjaimella! Ei hyvä. Pikaisella googlettelulla selvisi, että state-tiedostoon oikeaan kohtaan lisäämällä hipsut, pitäisi ongelman poistua.

Elikkäs:

sudoedit /srv/salt/statti/init.sls

  value: {{ pillar['value'] }}
Tulisi muuttaa:
  value: '{{ pillar['value'] }}'

Tallennus ja testaus:
sudo salt '*' state.apply statti

minttu_true.PNG

Hyvästi isot alkukirjaimet! Hipsukikka toimi.

Todistusaineistoa:

sudo salt '*' pillar.items

pillaritems_cmd.PNG

Lisätyt valuet näkyvät oikeiden orjien kohdalla.

Sar-komento lakkasi keräämästä laitetietoja toni_vp-orjalla ja jatkoi toimintaansa toniminttu-orjalla. Sar-komento ei kuitenkaan enää toistanut alkuperäistä virheilmoitustaan, vaan se näyttää keräämänsä tiedot siltä ajalta kun se oli ollut päällä.

c) Tee kahdella orjalla esimerkki, jossa toinen orja saa muuttujan pilarista ja toinen käyttää oletusarvoa (pillar.get). Tee jokin muu kuin tunnilla tehty sshd-esimerkki.

Tähän tehtävään hain apuja Tero Karvisen Secrets in Salt Pillars -artikkelista.

Tehtävästä pitäisi selvitä pienillä muutoksilla init-tiedostoon:

sudoedit /srv/salt/statti/init.sls

Aiemman kohdan pillar[‘value’] tulisi muuttaa pillar.get -komennoksi:

/etc/default/sysstat:
  file.managed:
    - source: salt://statti/sysstat.txt
    - template: jinja
    - context:
      value: '{{ pillar.get('value', 'toot') }}'

Ideana on, että tila hakee value-muuttujan pillarista ja jos sitä ei jostain syystä löydy niin se käyttää “toot”-tekstia sen sijaan. Kävin vielä kommentoimassa pillarin top-tiedostosta minttusar-tilatiedoston pois, joten tässä kävisikin juuri edellä mainitulla tavalla.

sudo salt '*' state.apply statti

toot_changes2.PNG

Toimii juuri niin kuin pitää!

Testauksen jälkeen vaihdoin tuon “toot” -tekstin init.sls-tiedostosta muotoon “true”, jotta tässä olisi jotain järkeä.  Kävin myös ottamassa pillarin top-tiedostosta tekemäni kommentin pois. Nyt siis orja saisi aina /etc/default/sysstat-tiedostoon “true”:n arvoksi, jos se ei jostain syystä pääsisi pillariin käsiksi.

Toni Hukka
22.4.2018

H3: Jinja ja SLS-tilat

Tehtävänannot kopioitu Tero Karvisen kurssisivulta.

b) Tiedosto muotista: tee yksinkertainen SLS-tilatiedosto, joka laittaa muuttujan tiedostoon. Käytä jinjan kontekstimuuttujaa (template: jinja, context: …).

Aloitin tehtävän purkamisen luomalla sls-tilatiedoston ja kansion sille:

sudo mkdir /srv/salt/h3/
sudoedit /srv/salt/h3/muuttuja.sls

Tiedoston sisältö:

/tmp/wubwub.txt:
  file.managed:
    - source: salt://h3/fill.txt
    - template: jinja
    - context:
    filu: ja hiiohoi

Kyseinen tilatiedosto siis loisi tmp-hakemistoon uuden tiedoston (wubwub.txt), käyttäen pohjana /srv/salt/h3/fill.txt-tiedostoa (tässä vaiheessa tiedostoa ei vielä ole, mutta luon sen heti seuraavaksi). Tilatiedosto myös määrittelee, että pohjana käytetään jinjaa, ja muuttujan “filu” sisällöksi tulee “ja hiiohoi”.

Sourcena käytettävän tiedoston luonti ja sisältö:

sudoedit /srv/salt/h3/fill.txt
--- sisältö ---
heipsuliveipsuli {{ filu }}
--- sisältö ----
ctrl x + y tallennus ja poistuminen

Suoritetaan luotu tila kaikille minioneille:

sudo salt '*' state.apply h3/muuttuja

h3_1.png
Käydään lukemassa tmp-hakemistosta syntynyt tiedosto:

h3_2.png

Tekstissä ollut muuttuja {{ filu }} oli nyt “korvaantunut” tilatiedostossa määritellyllä”ja hiiohoi” -tekstillä, joten tämä näyttäisi toimivan niin kuin pitää.

Mielenkiinnon vuoksi kokeilin myös, että ovatko {{ filu }} ja {{filu}} sama asia (välilyönnit) Saltissa. Molemmat näyttäisivät antavan saman lopputuloksen.

h3_3.png

c) SLS tilaa Jinjalla: tee yksinkertainen SLS-tilatiedosto, joka käyttää for-in -silmukaa. Voit esimerkiksi tehdä kolme tiedostoa silmukalla. (Tässä tehtävässä siis käytetään jinjaa vain SLS-tiedoston sisällä, älä sotke samaan esimerkkiin tekstitiedostojen sisällön muuttamista.)

Loin harjoitusta varten uuden kansion ja tilatiedoston:

sudo mkdir /srv/salt/h3c/
sudoedit /srv/salt/h3c/init.sls

Tiedoston sisällöksi sovelsin aiemmalla oppitunnilla tehtyä harjoitusta:

{% for tiedosto in ['testi1', 'testi2', 'testi3'] %}

/tmp/h3c/{{tiedosto}}.txt:
  file.managed:
    - makedirs: True

{% endfor %}

Tilan idea on aika simppeli, se suorittaa for-looppia niin kauan kunnes ensimmäisellä rivillä määritetyt kolme tiedostoa (testi1, testi2 ja testi3) ovat luotu /tmp/h3c/ -kansioon. Tila myös luo kansion tarvittaessa (makedirs: True). Tiedostot saavat .txt-päätteen rivin kolme ansiosta.

Kokeilu:

sudo salt '*' state.apply h3c

 

h3_4.png

Tarkistetaan vielä kansiosta:

h3_5.png

Hyvältä näyttää!

d) SSH-demonin portti: tee tila, joka asentaa SSH-demonin valittuun porttiin. Käytä portin valintaan Jinjaa, siten että sshd_config:issa “Port:”-kohdan arvo tulee Jinjan muuttujasta.

Sovelsin tätä tehtävää varten Tero Karvisen sivuilta löytyviä ohjeita SSH-portin vaihtamiseen Saltilla.

Aloitin jälleen kansion ja tiedoston luonnilla. Kopioin myös sshd-asetukset ilman kommenttirivejä:

sudo mkdir /srv/salt/ssh_portti
cd /srv/salt/ssh_portti
sudo cp /etc/ssh/sshd_config .
grep -v "#" sshd_config | sudo tee sshd.txt (luo uuden tiedoston, jossa ei ole kommenttirivejä)
sudo rm sshd_config (poistetaan kommenttirivit sisältävä tiedosto)

Luodaan tilatiedosto ja muokataan sitä toteuttamaan haluttu asia:

sudoedit init.sls

Sisältö:

openssh-server:
  pkg.installed

/etc/ssh/sshd_config:
  file.managed:
    - source: salt://ssh_portti/sshd.txt
    - template: jinja
    - context:
      Porttinumero: 1234

sshd:
 service.running:
    - watch:
     - file: /etc/ssh/sshd_config

Boldattuna tekemäni muutokset verrattuna Teron sivuilta löytyvään versioon. Puretaan tiedostoa hieman: ensiksi tila katsoo, että openssh-server on asennettuna, tämän jälkeen käsketään tiedostoa käyttämään /etc/ssh/sshd_config -tiedoston lähdetiedostona samaisesta kansiosta löytyvää sshd.txt-tiedostoa (aiemmassa kohdassa juuri luotu). Kyseisestä tiedostosta kaikki muuttujat nimeltä {{Porttinumero}} saavat arvokseen 1234. Viimeiseksi tila vielä katsoo, että palvelu on päällä ja resettaa sen jos sshd_config-tiedosto kokee muutoksia.

Nyt vielä on lisättävä {{Porttinumero}} tuonne sshd.txt-tiedostoon.

sudoedit sshd.txt

sshd_porttinumero_variaabeli.png

Ajetaan tila kaikille minioneille:

sudo salt '*' state.apply ssh_portti

h3_ssh_portti1.png

Näyttää lupaavalta. Kommenttirivit lähtivät pois ja porttikin muuttui 1234.

Testataan vielä kirjautumalla:

ssh_testi

Portti 22 ei toimi ja vaihdettuun porttiin 1234 pääsin kirjautumaan sisään, joten tämäkin toimii halutulla tavalla!

e) Kokeile jonkun toisen opiskelijan tekemää Salt-tilaa. Kokeiltava tila voi olla mistä vain harjoituksesta. Opiskelijoiden raportteja ja koodeja löydät tämän sivun perästä kommenteista.

Päätin kokeilla Marcus K:n aikavyöhykettä vaihtavaa Salt-tilaa. Ohjeet löytyvät kohdasta F.

cd /srv/salt/
sudoedit timezone.sls

Tiedoston sisältö (tarkoituksella väärä timezone):

America/Denver:
  timezone.system

Tallennus ja ajetaan salt-tila:

sudo salt '*' state.apply timezone

timezone.png

Tarkistin googlella niin Denverissä kello toden totta oli 08:55. Vaihdoin tämän jälkeen .sls-tiedostoon “America/Denver” tilalle “Europe/Helsinki” ja suoritin salt-tilan uudelleen, saadakseni minionin takaisin oikealle aikavyöhykkeelle.

timezone_2.png

Ookoo!

Kotitehtävä #2

b) Laita käyttäjien kotisivut toimimaan Apachella.

Testaus käsin:

  1. Apachen asennus
    sudo apt-get update
    sudo apt-get install -y apache2
  2. Luodaan käyttäjänä kotihakemistoon public_html -kansio:
    mkdir public_html
  3. Luodaan kotihakemistoon testisivu:
    cd public_html/
    sudo nano index.html (jotain tekstiä tiedoston sisään)
  4. Enabloidaan käyttäjien kotihakemistot Apachessa:
    sudo a2enmod userdir
    sudo systemctl restart apache2.service
  5. Testataan kurkkaamalla osoitetta http://localhost/~käyttäjänimi selaimen kautta – toimii!testi.png

Tässä vaiheessa päätin kopioida Apachen tekemät asetustiedostot /srv/salt/apache-kansioon, joita tulen jatkossa tarvitsemaan.

sudo mkdir /srv/salt/apache/ (luodaan kansio)
cd /srv/salt/apache/
sudo cp /var/www/html/index.html . (kopioidaan tarvittavat tiedostot, piste cp-komennon perässä kopioi tiedostot siihen kansioon, jossa sijaitaan)
sudo cp /etc/apache2/mods-enabled/userdir.conf .
sudo cp /etc/apache2/mods-enabled/userdir.load .

Seuraavaksi lähdin poistamaan koko apachen asennusta. Tämä onnistui helpoiten purgeemalla se pois:

sudo apt-get purge apache2

Nyt pystyin aloittamaan puhtaalta pöydältä tiloilla kikkailun.

Luodaan init.sls, joka tulee sisältämään kaikki tärkeät asetukset:

cd /srv/salt/apache/
sudo nano init.sls

Ensimmäiseksi halusin varmistaa, että pystyn tilan kautta asentamaan Apachen, ilman mitään muita muutoksia asetuksiin. Init.sls -tiedoston sisällöksi tuli siis pelkästään:

apache2:
  pkg.installed

Asennuksen kokeilu:

sudo salt '*' state.apply apache ('*' = kaikille minioneille, apache = kansion nimestä osaa hakea init.sls-tiedoston)

apache_asennus_state

OK!

Seuraavaksi loin symlinkit userdir-asetuksiin init.sls-tiedostoon. Samalla myös vaihdoin Apachen default websiten käyttämään aiemmin kopioitua apache-kansiossa olevaa versiota.

cd /srv/salt/apache/
sudo nano index.html (laitetaan jokin testiteksti)
Tiedoston tallennus ja takaisin terminaaliin
sudo nano init.sls

Init.sls uusi ulkomuoto Tero Karvisen ohjeiden mukaan:

apache2:
  pkg.installed

/var/www/html/index.html:
  file.managed:
    - source: salt://apache/index.html

/etc/apache2/mods-enabled/userdir.conf:
  file.symlink:
    - target: ../mods-available/userdir.conf

/etc/apache2/mods-enabled/userdir.load:
  file.symlink:
    - target: ../mods-available/userdir.load

apache2service:
  service.running:
    - name: apache2
    - watch:
    - file: /etc/apache2/mods-enabled/userdir.conf
    - file: /etc/apache2/mods-enabled/userdir.load

Kokeilin taas poistaa koko roskaa ja lähteä nollasta, elikkäs:

sudo apt-get purge apache2
sudo salt '*' state.apply apache

Tekstiä vilisi ja lopulta raportti ilmoitti:

Succeeded: 5 (changed=4)
Failed: 0

Varmistin vielä selaimen kautta molemmat paikat http://localhost ja http://localhost/~bere/ – molemmat toimivat! Olin myös kokeillut purgen jälkeen osotteita, jolloinka ne eivät oletetusti toimineet. Tämä state näyttäisi siis toimivan juuri niin kuin pitää.

c) Laita PHP toimimaan käyttäjien kotisivuilla. (Huomaa, että PHP toimii oletuksena kaikkialla muualla kuin käyttäjien public_html-kotisivuilla.)

Asensin käsin php-moduulin ja kävin kommentoimassa risuaidat /etc/apache2/mods-available/php7.0.conf-tiedostoon ja resetoin apache2-servicen. Tämän jälkeen testasin, että php toimii käyttäjän kotisivuilla. Testi toimi ja päätin tässä vaiheessa kopioida php7.0.conf -tiedoston risuaitoineen omaan /srv/salt/apache -kansiooni. Päätin myös kopioida php7.0.load -tiedoston, vaikka minusta tuntuu, että asetus toimii myös ilman sitä.

Kopiointi:

cd /srv/salt/apache/
sudo cp /etc/apache2/mods-available/php7.0.conf .
sudo cp /etc/apache2/mods-available/php7.0.load .

Tämän jälkeen lähdin muokkaamaan hyväksi todettua init.sls -tiedostoa. Boldattuna lisäykset aiempaan tehtävään verrattuna. Muutokset asentaisivat aina libapache2-mod-php:n jos sitä ei ole ja myös resetoisivat sen, jos se ei ole päällä.

apache2:
 pkg.installed

libapache2-mod-php:
 pkg.installed

/etc/apache2/mods-available/php7.0.conf:
 file.managed:
 - source: salt://apache/php7.0.conf

/etc/apache2/mods-available/php7.0.load:
 file.managed:
 - source: salt://apache/php7.0.load

/var/www/html/index.html:
 file.managed:
 - source: salt://apache/index.html

/etc/apache2/mods-enabled/userdir.conf:
 file.symlink:
 - target: ../mods-available/userdir.conf

/etc/apache2/mods-enabled/userdir.load:
 file.symlink:
 - target: ../mods-available/userdir.load

apache2service:
 service.running:
 - name: apache2
 - watch:
 - file: /etc/apache2/mods-enabled/userdir.conf
 - file: /etc/apache2/mods-enabled/userdir.load
 - file: /etc/apache2/mods-available/php7.0.conf
 - file: /etc/apache2/mods-available/php7.0.load

Uuden staten testaus. Purgetaan apache ja php-moduuli:

sudo apt-get purge apache2*
sudo apt-get purge php*

Kokeilin aiemmin purgea libapache2-mod-php, mutta tuo jätti aina jälkeensä jotain asetustiedostoja. Tappelin tämän kanssa varmaan kolme tuntia, kunnes tajusin kokeilla purgea koko php:lle.

Staten käynnistys:

sudo salt '*' state.apply apache

php_salt_state

Muutokset menivät läpi ja testasin kaiken toimivaksi. Alla vielä kuva sivusta, jonka php-koodi toimii.

toimii_php

d) Rakenna tila (state), joka tekee Apachelle uuden nimipohjaisen virtuaalipalvelimen (name based virtual hosting). Voit simuloida nimipalvelun toimintaa hosts-tiedoston avulla.

Ennen kuin lähdin rakentamaan tilaa, päätin kokeilla simuloidun nimipalvelun toimintaa. Muokkasin /etc/hosts -tiedostoa lisäämällä sinne rivin:

( sudo nano /etc/hosts )
192.168.0.105            suolatoni.example.com

Päivitys: Parempi laittaa osoitteeksi 127.0.0.1 niin domain toimii myös vaikka oma verkko vaihtuisi.

Käynnistin Apachen uusiksi ja kokeilin selaimella osoitetta http://suolatoni.example.com – toimi!

Seuraavaksi kopioin hosts-tiedoston /srv/salt -kansioon.

cd /srv/salt/
sudo cp /etc/hosts .

Rakensin samaan kansioon myös suola.conf-tiedoston.

sudo nano suola.conf

Tiedoston sisältö:

<VirtualHost *:80>
 DocumentRoot /home/bere/public_html/
 ServerName suolatoni.example.com
 ServerAlias www.suolatoni.example.com

<Directory /home/bere/public_html/>
 Require all granted
 </Directory>
</VirtualHost>

Nyt vuorossa oli sls-tiedoston luonti:

sudo nano vhosti.sls

Tiedoston sisältö:

/etc/hosts:
  file.managed:
    - source: salt://hosts

/etc/apache2/sites-available/suola.conf:
  file.managed:
    - source: salt://suola.conf

#/etc/apache2/sites-enabled/suola.conf:
# file.managed:
# - source: salt://suola.conf

a2dissite 000-default.conf:
  cmd.run

a2ensite suola.conf:
  cmd.run

apache2service:
  service.running:
    - name: apache2
    - watch:
#   - file: /etc/apache2/sites-enabled/suola.conf
    - file: /etc/apache2/sites-available/suola.conf
    - cmd: 'a2dissite 000-default.conf'
    - cmd: 'a2ensite suola.conf'

Kyseinen vhosti.sls -tiedosto lukee kansiossa olevat hosts- ja suola.conf -tiedostot ja käyttävät niitä päämäräisinä järjestelmän asetuksina. Tätä seuraa default-sivun disablointi a2dissite-komennolla ja tekemäni suola.conf-asetuksen enablointi. apache2service varmistaa, että Apache pyörii ja jos muutoksia tiedostoihin tai komentoja suoritetaan, niin Apache resetoituu.

Kokeilin staten toimivuutta disabloimalla käsin, sekä poistamalla tiedostot kansioista ja ajamalla tämän jälkeen “sudo salt ‘*’ state.apply vhosti”. Näiden kokeilujen perusteella tämä sls-tiedosto toimi kuin piti.

vhosti

Komento tosin aina antaa tuon ilmoituksen, että “already enabled”, mutta toimii kuitenkin.

e) Tee tila, joka laittaa esimerkkikotisivun uusille käyttäjille. Voit laittaa esimerkkikotisivu /etc/skel/:iin, niin se tulee automaattisesti ‘adduser tero’ komennolla käyttäjiä luodessa.

Ensimmäiseksi loin public_html-kansion manuaalisesti /etc/skel -polkuun.

cd /etc/skel/
sudo mkdir public_html

Tämän jälkeen vaihdoin takaisin /srv/salt/ -kansioon ja loin sinne uuden kansion:

cd /srv/salt/
sudo mkdir kotisivu

Luotuun kansion tein index.html -tiedoston, joka sisälsi seuraavat pätkät HTML:ää.

<html>
    <head> 
      <title>testi</title> 
      <meta charset="utf-8">
    </head>
<body> 
    <p>moikka toimiiko hellurei</p>
</body>
</html>

Samaiseen kansioon tein myös init.sls -tiedoston. Halusin saada kyseisen tiedoston käyttämään äsken luotua html-tiedostoa oletuksenaan. Sisällöksi tuli siis:

/etc/skel/public_html/index.html:
  file.managed:
    - source: salt://kotisivu/index.html

Enää testausta vaille valmis:

sudo salt '*' state.apply kotisivu

skel_index

Käyttäjän luonti:

sudo adduser mattinykanen

Testaus selaimen kautta:

mattinykanen.png

Skulaa!

f) Eri asetukset. Tee Package-File-Service tilalla eri asetuksia kuin ne, mitä tehtiin tunnilla; ja eri kuin mitä teit/teet h2 muissa kohdissa. Voit muuttaa jotain toista asetusta samoista demoneista tai valita kokonaan eri demonit.

Asensin ensiksi fail2ban-ohjelman staten kautta (luoden sille oman alikansion):

cd /srv/salt/
sudo mkdir banni
sudo nano init.sls

Tiedoston sisältö alkuun:

fail2ban:
  pkg.installed

Asennus ja tiedoston kopiointi:

sudo salt '*' state.apply banni
sudo cp /etc/fail2ban/jail.conf

banni1.png

Kopioidusta tiedostosta muokkasin banniajan hieman pidemmäksi:

sudo nano jail.conf

banni2.png

Nyt täytyisi init-tiedostoa vielä vähän muokata, ottamaan huomioon tuo uusi conf-tiedosto (boldilla lisätyt rivit):

fail2ban:
  pkg.installed

/etc/fail2ban/jail.conf:
  file.managed:
    - source: salt://banni/jail.conf

fail2ban_service:
  service.running:
    - name: fail2ban
    - watch: 
      - file: /etc/fail2ban/jail.conf

Tiedoston pitäisi nyt tarkkailla tuota samassa kansiossa olevaa jail.conf-tiedostoa ja käynnistettävä fail2ban uudelleen, jos se vastaanottaa mitään muutoksia.

banni3.png

Banniajan muokkaus onnistui! Testausta en valitettavasti voinut suorittaa.

Lähteet:

Tero Karvinen – Salt States

Tero Karvinen – Control Daemons with Salt

Tero Karvinen – Apache User Homepages Automatically

Linfo – /etc/skel

Digital Ocean – Fail2ban configuration

Tehtävänanto / kurssisivu: Tero Karvinen – Palvelinten Hallinta

Kotitehtävä #1

Linkki kurssisivulle ja tehtävänantoon: Tero Karvinen – Palvelinten hallinta.

c) Asenna Salt Master ja Slave pull-arkkitehtuurilla (eli master on server). Voit laittaa herran ja orjan myös samalle koneelle. Kokeile suorittamalla salt:illa komentoja etänä.

Slave-asennuksen aion asentaa läppäriin paikallisesti (Linux Mint 18.02) ja master-asennus taas tulee omistamaani Digital Oceanin virtuaalipalvelimeen (Ubuntu 16.04).

Salt-masterin asennus virtuaalipalvelimelle:

sudo apt-get update
sudo apt-get install -y salt-master

Tämän jälkeen minun täytyi selvittää masterin IP-osoite, jotta voin sen syöttää myöhemmin slave-koneelle.

Selvitys tapahtui komennolla:

hostname -I

Avasin myös Salt Masterin käyttämät portit 4505 ja 4506:

sudo ufw allow 4505/tcp
sudo ufw allow 4506/tcp

Toimenpiteet slave-koneella.

Salt-minionin asennus:

sudo apt-get update
sudo apt-get install -y salt-minion

Muokataan /etc/salt/minion-tiedostoon master-koneen osoite ja orjakoneen ID:

sudo nano /etc/salt/minion
/* viimeisille riveille lisätään: */
master: ip-osoite
id: orja
sudo systemctl restart salt-minion.service

minion.png

Tämän jälkeen täytyy hyväksyä Master-palvelimella lisätty key:

sudo salt-key (katsotaan löytyykö listasta)
sudo salt-key -A (hyväksytään kaikki)

key.png

 

Varmistetaan että masterin ja slaven välinen yhteys toimii:

Master-koneelta:

sudo salt '*' cmd.run 'whoami' (* = kaikille slaveille, tässä tapauksessa vain yksi slave)

toimii.png

Toimii!

d) Kokeile jotain Laineen esimerkistä lainattua tilaa tai tee jostain tilasta oma muunnelma. Muista testata lopputuloksen toimivuus. Huomaa, että varastossa on myös keskeneräisiä esimerkkejä, kuten Battlenet-asennus Windowsille.

Tiloja varten tarvitsin kansion /srv/salt/.

cd /srv/
mkdir salt

Tein salt-kansion sisälle ohjelma.sls-nimisen tiedoston nanolla. Valitsin Joona Leppälahden lamp.sls-tiedoston, jota muokkasin omaan käyttööni seuraavan näköiseksi:

peli:
  pkg.installed:
    - pkgs:
      - ninvaders

Tila asentaisi Ninvaders-pelin halutulle slave-koneelle komennolla:

sudo salt '*' state.apply ohjelma

Tämä ei kuitenkaan toiminut kertaheitolla, vaan järjestelmä antoi seuraavan virheilmoituksen:

orja:
----------
 ID: peli
 Function: pkg.installed
 Result: False
 Comment: State 'pkg.installed' was not found in SLS 'ohjelma'
 Reason: 'pkg' __virtual__ returned False
 Started: 
 Duration: 
 Changes:

Summary for orja
------------
Succeeded: 0
Failed: 1

Yritin tätä yli tunnin googletella, mutta en ole vielä onnistunut löytämään mitään ratkaisua asiaan. Kokeilin myös antaa suoraan komennon “sudo salt ‘*’ pkg.install ninvaders”, mutta tämäkin tarjosi vain virhettä “‘pkg.install’ is not available.”

Yritän vielä myöhemmin selvitellä tätä lisää, mutta nyt siirryn seuraavaan tehtävään.

Päivitys: Mint-koneelle ei asennus vieläkään onnistu, mutta palvelimelle asennetulle minionille state lähti toimimaan (vaati kyllä hieman viilausta).

vp_orja.PNG

Vp_orja (virtuaalipalvelimen minion) antoi myös erroria tuota ohjelma.sls-tilaa ajettaessa.

Pienellä googlauksella selvisi, että repo pitäisi vaihtaa. Ajoin virtuaalipalvelimella komennon:

sudo add-apt-repository --remove ppa:saltstack/salt

Tämän jälkeen asennus onnistui.

vp_orja1.PNG

Päivitys 08.04.2018: Sain vihdoinkin korjattua tuon Mint-konetta riivanneen ongelman. Ongelma katosi kun päivitti salt-masterin ja salt-minionin uusimpaan versioon. Kyseinen ongelma ilmeni siis ainakin 2015.8.8-versiossa, joku oli korjannut ongelman palaamalla versioon 2015.5.10 -versioon. Päivitin itse salt-minionin ja salt-masterin uusimpaan versioon Saltstackin ohjeiden avulla.

Version pystyy tarkistamaan komennolla:

salt-master --version (tai salt-minion --version)

Päivityksen jälkeen komento “sudo salt ‘*’ pkg.install ninvaders” toimi ongelmitta. Jes!

e) Kerää laitetietoja koneilta saltin grains-mekanismilla.

Kokeilin antamalla komennon

sudo salt '*' grains.item cpu_model

Joka antoi juuri oikean tuloksen:

prossu.png

f) Oikeaa elämää. Säädä Saltilla jotain pientä, mutta oikeaa esimerkiksi omalta koneeltasi tai omalta virtuaalipalvelimelta. (Kannattaa kokeilla Saltia oikeassa elämässä, mutta jos se ei onnistu, rakenna jotain oikeaa konettasi vastaava virtuaaliympäristö ja tee asetus siinä).

Ajattelin kokeilla lukea auth.logia saltin kautta molemmilta koneilta. Komennoksi väkersin:

sudo salt '*' cmd.run 'tail -50 /var/log/auth.log|grep invalid'

Valitsin 50 viimeistä riviä, joissa esiintyy sana “invalid”. Orja-kone ei tuottanut tuloksia, koska se ei toimi minkäänlaisen palvelimen virassa, mutta virtuaalipalvelin (vp_orja) tuotti haluttuja tuloksia.

authlog.PNG

Lähteet:

Tero Karvinen – Salt Quickstart. URL: http://terokarvinen.com/2018/salt-quickstart-salt-stack-master-and-slave-on-ubuntu-linux

Tero Karvinen – Salt States. URL: http://terokarvinen.com/2018/salt-states-i-want-my-computers-like-this

Saltstack, running commands. URL: https://docs.saltstack.com/en/latest/topics/execution/remote_execution.html