This is an old revision of the document!


Tema 2

* Publicare:

  • 2022-12-07 18:00

* Termen de predare:

  • 2022-12-20 23:55 - deadline HARD

Revizii:

  • 2022-12-08 14:00: Adăugat notiță la cerința 10 (mail script).
  • 2022-12-08 10:00: Checker nou, v2022.2.0 ce definitivează verificările la taskurile 11-12 + modificări în enunț la task 12 (vedeți notița de la final, plus: portul este TCP v4 nu v6).
  • 2022-12-08 08:00: Checker nou, v2022.1.0: implementat verificarea ex. 10.
  • 2022-12-07 18:35: Reparat problemă chei publice pe OpenStack (imagine nouă: RL 2022 Tema2 v1.1)

Tema constă în realizarea configurației unui set de exerciții pe o topologie (vedeți mai jos) simulată folosind containere (implementare în ContainerNet + Docker) într-o mașină virtuală (ori în cloud - OpenStack, ori descărcată local).

Notare

Fiecare exercițiu are un punctaj propriu. Nota pe întreaga temă este dată de suma punctajelor acumulate în urma rezolvării fiecărui exercițiu.

Punctajul maxim care se poate obține pe întreaga temă este 100 de puncte. Acest punctaj este echivalent cu 1.8 puncte din nota finală.

Există și exerciții bonus, cu ajutorul cărora puteți obține 125 de puncte.

Nu este obligatorie rezolvarea tuturor exercițiilor. Exercițiile pot fi rezolvate în orice ordine, mai puțin în situația în care un exercițiu depinde de rezolvarea unui alt exercițiu (de obicei, primele 4 de stabilire a conectivității containere – Internet).

Topologie

Fapt divers: VLAN9 se numește rețeaua de pe OpenStack, dacă rulați local, acolo va fi rețeaua hivervizorului (VMWare / VirtualBox) cu mașina fizică.

Mașina virtuală

Utilizare

  • Puteți rezolva tema ori folosind infrastructura OpenStack (aveți proiect special numit rl_tema2_prj - meniu stânga sus, lângă logo OpenStack - unde găsiți și imaginea), ori o mașină virtuală locală (citiți mai jos).
  • Notă: pe OpenStack, autentificarea cu username și parolă nu este posibilă! Folosiți autentificarea cu chei publice, prezentată aici. Va
  • Pentru autentificare pe VM local, utilizați credențialele student/student.

Pași pentru accesare OpenStack

  • Urmăriți pașii din laboratoare.
  • Va trebui să vă importați cheia publică pe acest proiect nou rl_tema2_prj (proiectul de laborator este diferit, rl_prj);
  • Nume imagine (de selectat la Sources): RL 2022 Tema2 v1.1;
  • Tip instanță: m1.small (NU aveți nevoie de mai mult);
  • Puneți la VM un nume care să vă conține numele (sau username-ul de Moodle) vostru (dacă veți avea nevoie de ajutor din partea unui asistent, să vă găsim ușor);
  • OBLIGATORIU: autentificarea cu user și parolă a fost dezactivată, folosiți EXCLUSIV chei publice ssh (pe care ar trebui s-o aveți deja configurată în cadrul laboratoarelor).
  • NU modificați parola la conturile root / student! Dacă vă tăiați accesul la VM din greșeală, cereți ajutorul unui asistentului preferat pe Teams ;)

Atenție! NU distrugeți instanța mașinii virtuale până nu ați încărcat arhiva finală pe RL Checker și ați obținut punctajul dorit (și să fiți siguri că nu veți mai avea nevoie să modificați nimic).

Rulare în VM local

  • Pentru a rula mașina virtuală a temei local, o puteți descărca de la acest URL (4.6GB).
  • VM-ul este compatibil atât cu VirtualBox (testat cu 6), cât și VMWare (testat cu Workstation >= 16). Pe Linux, poate fi rulat și prin qemu+kvm.
  • Va trebui să vă creați mașină virtuală nouă în hipervizorul preferat (VMWare / VirtualBox / etc.) și să importați fișierul vmdk (căutați pe Google documentație, pașii diferă în funcție de programul de virtualizare folosit).
  • Accesul prin ssh cu parolă este activat, deoarece VM-ul rulează pe o rețea privată.
  • Dacă întâmpinați probleme, creați un proiect de mașină virtuală nouă și atașați-i disk-ul existent vmdk.
  • Atenție: Imaginea VM-ului diferă de cea a laboratorului, asigurați-vă că îl descărcați pe cel corect!

Verificarea temei

  • Mașina virtuală conține checkerul (sursă închisă) și dispune de scripturi pentru a face actualizarea și rularea sa mai simplă.
  • Pentru verificarea temei este disponibil un checker local. Atenție: nu este substitut pentru depanare!
    • Altfel spus, contează soluția voastră, nu checker-ul.
    • Dacă, dintr-o greșeală, checker-ul dă rezulat pozitiv în cazul unui exercițiu rezolvat greșit nu înseamnă că se va puncta. O eventuală actualizare a checker-ul va puncta corect.
    • Obiectivul trebuie să fie rezolvarea corectă a enunțului. Checker-ul vine ca o confirmare (ne dorim cât mai sigură) a acelei rezolvări.
    • Punctajul afișat pe RL Checker va fi și cel acordat în catalog la final.
  • Play fair: orice tentativă de fraudare / atac la infrastructură va avea ca efect pierderea definitivă a punctajului (sau chiar repetarea materiei, în anumite cazuri), chiar dacă checkerul este păcălit :P.
  • Înainte de a rula checkerul, se recomandă descărcarea ultimului update prin rularea:
    root@host$ t2update
  • Comenzile de mai jos pot fi rulate indiferent de directorul in care ne aflăm.
  • Pentru a actualiza checker-ul:
    t2update
  • Pentru a rula checkerul:
    t2check
  • Exemple de folosire:
    root@host:~# t2check 
    task01       .........................  10.0/10.0
    task02       .........................  10.0/10.0
    task03       .........................  10.0/10.0
    task04       .........................  10.0/10.0
    ...
    
    root@host:~# t2check 10
    task10       .........................  0.0/10.0
       mail not received
  • Dacă sunt probleme, puteți să postați un mesaj pe thread-ul aferent de pe forum;

Predarea temei

  1. Pentru urcare soluție, rulați:
    root@host$ t2check --save
  2. Rezultatul este o arhivă semnată în directorul în care invocați comanda.
  3. Folosind utilitarul scp, copiați acest fișier pe stația voastră locală (atenție să nu încurcați directoarele și să copiați o arhivă veche / salvată în altă parte!). Dacă sunteți conectat la OpenStack prin serverul intermediar fep.grid.pub.ro, va trebui să copiați mai întâi acolo, apoi s-o preluați pe stația voastră de lucru (alternativ, puteți folosi funcționalitatea de ProxyCommand a clientului ssh pentru o conexiune directă).
  4. Încărcați arhiva pe RL Checker (Moodle).

Recomandăm ca rezolvarea exercițiilor trebuie să se facă în mod persistent. La o repornire a mașinii virtuale, rezolvările trebuie să rămână active, altfel puteți întâmpina dificultăți la o revenire ulterioară asupra temei.

Folosiți comanda reboot înainte să testați de-a întregul (checkerul local doar simulează ceva mai rapid).

De asemenea, puteți folosi comanda systemctl restart rl-topology pentru a reporni rapid toate containerele (sistemul lor de fișiere este și el persistent).

Pentru a rezolva tema este îndeajuns să prelucrați fișiere doar din căile /etc, /home și /root (atât pe host, cât și pe containere). NU instalați alte pachete în plus.

NU opriți / ștergeți manual containerele (decât dacă doriți să luați de la zero cu configurarea acestora).

Pentru a șterge și reseta configurația de pe un container, se recomandă secvența:

systemctl stop rl-topology && docker container rm <nume container> && systemctl restart rl-topology;

Personalizarea temei

Rezolvările sunt particularizate pentru fiecare student (pe baza contului Moodle). Pentru a obține aceste date, accesați link-ul Moodle RL Checker.

Datele de particularizare afișate pe Moodle vor fi introduse şi în fişierul /root/assignment.txt de pe host, unde va trebui să păstrați formatul text VARIABILA=valoare (liniile noi în plus nu contează)! Atenție: nu puteți personaliza aceste valori, ele fiind verificate cu strictețe de către checker-ul online! Includeți ȘI variabila USERNAME!

Informațiile generate anterior vor fi folosite în enunțul temei cu următoarele notații:

  • $A - valoarea variabilei A
  • $B - valoarea variabilei B
  • $C - valoarea variabilei C

Discuții legate de temă

Toate discuțiile legate de probleme/întrebări/exerciții din tema de RL trebuie puse pe forumul temei. Reguli de utilizare ale acestui forum:

  • Nu se pun rezolvări directe pe forum.
  • Fiecare întrebare legată de un task trebuie pusă pe thread-ul dedicat acelui task.
  • În momentul în care puneți o întrebare, includeți în mesaj:
    • contextul în care a apărut problema pe care o semnalați
    • ce ați încercat să faceți pentru a repara problema
    • alte informații care pot descrie mai bine problema
    • dacă este vorba de rezolvarea unui task, cum ați verificat rezolvarea task-ului
  • Verificați dacă cineva nu a mai întâmpinat aceeași problemă și i-a fost oferit un hint sau o soluție (lurk before you leap).
  • Post-uri care nu sunt puse pe thread-ul corespunzător vor fi șterse.
  • Nu creați thread-uri noi (off-topic) de discuție! Vor fi șterse.

Subiecte

Toate configurațiile să fie persistente. Trebuie să fie active și după repornirea mașinii virtuale.

Pentru modificarea unor fișiere speciale din containerele Docker (/etc/hosts, /etc/resolv.conf) va trebui să folosiți un script de init sau hook de ifupdown. Găsiți mențiuni adecvate la exercițiile unde va fi necesar să faceți asta.

Va trebui să realizați primele 4 exerciții în ordine. Întrucât aceste exerciții oferă, în final, conectivitate la Internet, restul se vor baza pe acestea!

Dacă folosiți mai multe scripturi (apelați dintr-un script alt script), folosiți căi absolute. Adică folosiți /root/scripts/make-juju.py în loc de ./make-juju.py pentru a nu se baza pe directorul actual de lucru (working directory).

Nu trebuie instalați nimic în plus pe mașina virtuală, nu ar trebui să fie nevoie.

Se recomandă citirea întregului set de exerciții înainte de rezolvarea temei. În mod asemănător, la rezolvarea unui exercițiu se recomandă citirea întregului subset de exerciții.

Ex. 1 [20 puncte] Adresare + rutare IPv4

  1. Configurați cu adrese IP toate legăturile din topologie, astfel:
    • Rețeaua cu Router0, PC1, PC2: 10.11.$A.0/28, unde Router0 va avea prima adresă asignabilă, apoi PC1, apoi PC2 (fix în această ordine!); ATENȚIE: pe Router0 aveți bridge-ul declarat în /etc/network/interfaces.d.
    • Rețeaua host - PC-X: 172.18.$B.8/29
    • Rețeaua cu host - Router0: 172.18.$B.16/30
    • Sistemul host va avea mereu prima adresă asignabilă în rețelele la care participă!
  2. Mai departe, configurați rutarea IPv4 astfel încât toate stațiile să poată accesa host-ul (PC1 și PC2 îl vor folosi ca intermediar pe Router0, iar restul containerelor îl vor avea ca ruter implicit pe host).
  • Observație: adresa IP de pe eth0 a sistemului host este asignată dinamic de către hipervizor, prin DHCP; NU vă atingeți de această interfață, altfel riscați să vă pierdeți accesul la VM!

Pentru a configura persistent rute adiționale, puteți folosi hook-ul up în /etc/network/interfaces (RTFM here).

Ex. 2 [10 puncte] Adresare IPv6

  1. Configurați adrese IPv6 pentru rețeaua Router0, PC1, PC2:
    • Folosiți spațiul 2022:12:$A:$B::/64
    • Aceiași ordine ca mai sus (la IPv4) Router0 va avea prima adresă asignabilă, apoi PC1 apoi PC2.
  2. Configuerați conectivitate IPv6 între Router0 și host:
    • Folosiți spațiul FEC0:1234:$B:$D::/64;
    • Prima adresă asignabilă este pentru host, a doua a lui Router0.
  3. Configurați rutarea IPv6 pentru a permite comunicarea între toate sistemele cu adresă IPv6.
    • Rețeaua cu PC-X NU are adresă IPv6 ;)

Fișierele /etc/network/interfaces* se parsează și execută linie cu linie, scripturile if[up|down] oprindu-se la prima eroare întâlnită. De exemplu, dacă aveți o configurație inet static cu o comandă ”up ip ro add invalid route…” și pe rândurile următoare aveți declarații cu ”inet6”, acestea nu vor mai ajunge să fie aplicate!

Puteți folosi următorul oneliner pentru a verifica rapid o interfață:

ifdown --force <intf>; ifup --force <intf>; ip a sh; ip ro sh;

Ex. 3 [5 puncte] Hosts

  • Realizați configurațiile necesare astfel încât echipamentele să poată fi accesate prin numele lor (folosiți numele host, Router0, PC1, PC2, PC-X - atenție la MaJuScUlE!). Adăugați intrări de hosts doar pentru adresele IPv4.

Fișierul /etc/hosts din containere este mai special (montat ca volum –bind de către Docker).. Acest lucru face ca orice modificare a acestuia să se piardă la fiecare restart al containerului (aka reboot al VM-ului sau restart al serviciului rl-topology). Dacă (și sigur) vreți să persiste, puteți să-l salvați în altă cale (e.g., /etc/hosts.orig și să-l restaurați mereu când pornește containerul printr-un hook de up în /etc/network/interfaces). RTFM aici ;)

Ah, și nu folosiți cp, folosiți cat + redirectare bash (fiind volum, nu puteți șterge + recrea fișierul, trebuie suprascris)!

Ex. 4 [10 puncte] Internet connectivity

  • Realizați configurațiile necesare pentru ca cele 4 containere sa aibă acces la Internet:
    • Configurați sistemul host astfel încât să facă translatarea doar pentru adresele IP configurate static pe interfețele containerelor, nu și pentru alte adrese din rețelele lor.
    • Configurați cele 3 containere pentru a putea accesa resurse din Internet pe baza numelor de domeniu al acestora (DNS).

Fișierul resolv.conf este gestionat de către Docker :( Aveți aceiași poveste cu Docker ca la exercițiul anterior ⇒ aceiași soluție :D

Ex. 5 [10 puncte] Network Address Translation

  • Configurați reguli de NAT pe sistemele host și Router0 (după caz, ori unul ori ambele :P), astfel:
    • Conexiunile pe Router0 la porturile (21000 + $G) și (22000 + $H) să conducă la conectarea ssh pe sistemele PC1 respectiv PC2.
    • Conectarea pe host la portul (12300 + $K) să conducă la conectarea pe tracker-ul de pe sistemul PC-X
  • Sfat: aveți grijă cum testați: DNAT-ul va funcționa DOAR dacă veniți dintr-o rețea externă stației vizate ;)

Ex. 6 [10 puncte] Filtrare pachete (iptables)

  • Configurați filtrarea de pachete pe host și / sau Router0 (după caz) astfel încât:
    • conexiunile SMTP inițiate de pe sistemul PC1 să fie blocate (inclusiv către host!);
    • conexiunile către tracker-ul ce rulează pe sistemul PC-X să nu fie permise de pe PC2.
    • blocați TOATE conexiunile externe către PC1/PC2, mai puțin protocoalele icmp, ssh și ftp.
    • atenție: NU blocați conexiunile inițiate de PC1/PC2 sau răspunsurile de la acestea! folosiți reguli stateful;

Ex. 7 [10 puncte] Chei SSH

  • Configurați serviciul de SSH pe toate sistemele PC* și host astfel încât autentificarea cu utilizatorul student de pe oricare sistem să fie permisă pe toate celelate sisteme (tot în cadrul utilizatorului student) folosind chei publice;
  • Folosind alias-uri SSH să fie folosite comenzi simplificate pentru autenficarea pe sisteme:
    • ssh pc1 să ducă către sistemul PC1 cu utilizatorul student;
    • ssh pc2 să ducă către sistemul PC2 cu utilizatorul student;
    • ssh pc-x să ducă către sistemul PC-X cu utilizatorul student;
  • Observație: ssh-copy-id utilizează autentificare ssh pe bază de parolă pentru a copia cheia. Mașina virtuală pe OpenStack nu permite astfel de autentificare pe host, așadar veți fi nevoiți să autorizați cheia publică manual in fișierul corespunzător!

Atenție: NU VĂ ȘTERGEȚI CHEIA DE LA OPENSTACK DIN FIȘIERUL DE AUTORIZAȚII! Vă veți pierde accesul la VM.. asigurați-vă când editați fișierul că nu modificați acea linie!!

Ex. 8 [10 puncte] Căutare recursivă pe server HTTP cu autentificare

  • Creați, pe sistemul PC1 scriptul /home/student/scripts/whereswaldo care să caute recursiv prin paginile de la http://host/.X/ și să găsească fișierul waldo.txt (e.g., http://host/.X/sub/cale/waldo.txt).
  • Scriptul va trebui să afișeze DOAR conținutul paginii găsite!
  • Va trebui să vă autentificați prin HTTP cu credențialele:
    • username: ana
    • password: face_ReLe
  • Desigur, trebuie mai întâi să descoperiți ce tip de autentificare să folosiți!

Ex. 9 [10 puncte] Descărcare / încărcare fișiere între servere

  • Pe sistemul host:
    • Realizați un script /root/scripts/file-upload care uploadează DOAR fișierele de forma this([XYZ])_([0-9]{1,5})\.txt (text fix this urmat de unul din caracterele X, Y sau Z, apoi orice număr de 1-5 cifre (va fi între 0-10000), și, în final, extensia .txt) din directorul curent la URL-ul către subdirectorul /home/fs/upload de pe PC1, autentificarea făcându-se cu parola 3TaLeNt1337.
    • Realizați un script /root/scripts/file-download care descarcă DOAR fișierele cu forma ([0-9]+)-([a-zA-Z]+)\.tar\.gz (adică orice număr, urmat de separatorul minus ('-'), un șir format DOAR din litere mici/mari, apoi extensia .tar.gz) de pe stația PC-X, din directorul /home/student/download-this/, cu destinația în directorul curent (la momentul rulării scriptului).
  • Puteți folosi orice utilitar doriți (ftp / rsync / scp), dar atenție: trebuie să filtrați cu grijă (și regex :P) fișierele!
  • În toate cazurile, aveți de a face DOAR cu fișiere (i.e., transfer non-recursiv); nu le copiați în alte subdidrectoare (trebuie duse/preluate direct la/în calea menționată), altfel acestea nu vor fi văzute de către checker!
  • Atenție: notația folosită de enunț este PCRE (Perl-Compatible Regular Expressions), însă acest format nu este implementat de majoritatea utilitarelor de copiere studiate (:P), deci va trebui să: improvise. adapt. overcome!
  • Pentru testare, puteți să vă creați fișierele necesare (checkerul va face acest lucru automat pentru el).

Ex. 10 [5 puncte] Email Script

  • Pe sistemul host este configurat un server de e-mail (SMTP).
  • Pe sistemul PC2, creați scriptul /root/scripts/ssh-keys-backup care să trimită un mesaj către contact@host ce va conține:
    • subiectul SSH Keys Backup
    • atașament cu fișierul ssh-keys.tar.gz care să conțină un backup făcut pe loc la PC2:/home/student/.ssh/*;
    • fișierul .tar.gz astfel creat va trebui să păstreze permisiunile originale ale fișierelor!
    • în mesaj să fie un hash sha256 al atașamentului.

Checkerul NU acceptă mesaje inline cu atașamente UUEncoded! Folosiți formate MIME Multipart.

Hint: scriptul nu trebuie să fie obligatoriu în bash, puteți folosi orice interpretor instalat în container ;)

Ex. 11 [Bonus - 10 puncte] Wireguard tunnelling

  • Configurați un tunel Wireguard între PC2 și PC-X.
    • Denumiți interfețele de tunel wg-rl pe ambele capete.
    • Folosiți rețeaua IPv4 10.99.$C.0/24 pentru capetele tunelului (PC-X va avea a prima adresă IP asignabilă, PC2 pe cea de-a doua).
  • Hint: nu uitați să activați rutarea!

Ex. 12 [Bonus - 15 puncte] Advanced port forwarding

  • Pe stația PC2 va fi pornit un serviciu special pe portul TCP 16661 care va asculta DOAR pe capătul de tunel wireguard creat anterior (checkerul îl va porni automat; pentru testare puteți folosi nc cu argumentul -s, trebuie să puteți trimite mesaje bidirecționale prin portul forwardat).
  • Configurați firewallul pe PC-X (aveți iptables instalat) pentru a realiza DNAT astfel încât conexiunile la PC-X portul 666 să ducă către acest serviciu ce rulează pe PC2.
    • Accesul la serviciu prin PC-X:666 va trebui să fie funcțional din orice rețea (e.g., încercați să vă conectați de pe host sau Router0)!
  • Restricție: este obligatoriu să folosiți DOAR rutare (care ar trebui să fie deja configurată la ex. anterior) + reguli iptables pentru a rezolva acest exercițiu. E.g., nu e voie să folosiți un serviciu auxiliar care să asculte pe portul 666 și să redirecționeze pachetele la PC2!
  • Hint: Folosiți tcpdump cu încredere peste tot ;)

Am uitat să instalăm iptables pe containerul CT-X (necesar pentru ultimul bonus). ⇒ instalați-l manual ;) nu uitați să dați apt update înainte (containerele au listele de pachete șterse).

rl/teme/tema2.1670509583.txt.gz · Last modified: 2022/12/08 16:26 by florin.stancu
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0