* Publicare:

• 2025-12-02 11:00

* Termen de predare:

• 2025-12-15 23:55 - deadline HARD!

Revizii:

• 2025-12-05 23:00: Task 06 (DNAT): modificare enunț! host portul 18000+H trebuie să ducă către serverul HTTP al României (ori suntem daci ori nu mai suntem)! Checkerul deja verifica asta :D A fost schimbare de ultim moment (task-ul fiind mult mai dificil dacă se făcea DNAT spre Italy datorită rutelor multiple) și am uitat de enunț…
• 2025-12-04 16:45: Checker v2025.3: another day, another bug… UPDATE toți cei de pe OpenStack, am făcut optimizări drastice asupra memoriei utilizate de checker (cleanup) + 1GB zswap!
• 2025-12-03 22:20: Checker v2025.2: pus enforcement ca să nu mai funcționeze trolleala cu reboot pe OpenStack, UPDATE ASAP!
• 2025-12-03 9:30: Checker v2025.1: reparat problema cu t2check –save pe OpenStack (crăpa conexiunea SSH din cauza cloud-init-ului care, când repornea, repornea automat și serviciul networking chiar dacă era totul OK); ACUM MERGE SAVE-ul (doamne-ajută)!
• 2025-12-02 21:00: Imagine pe OpenStack v2025.1: pus lock la password auth pe student! GATA, ne calmăm cu ASCII “art”-ul prin consolele altora, da?
• 2025-12-02 11:00: Tema a fost lansată ;)

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ă și rulată local).

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 (tot ce este peste se trunchiază strict, per temă). Acest punctaj este echivalent cu 1.3 puncte din nota finală.

Există și exerciții bonus, cu ajutorul cărora puteți obține un total de 125 de puncte (remember: se trunchiază, dar pot fi folosite pentru a completa punctaj parțial la alte task-uri ne-esențiale – vedeți mai jos).

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).

• Puteți rezolva tema ori folosind infrastructura OpenStack (aveți proiect special numit rl_tema_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 (ATENȚIE: cheile SSH utilizate la laborator rămân disponibile pe TOATE proiectele, deci aveți setupul deja făcut!).
• Pentru autentificare pe VM local, utilizați credențialele student/student.

• Urmăriți pașii de la laborator sau de aici (ISC).
• Link dashboard: https://cloud.grid.pub.ro/
• Schimbați proiectul din dropdown-ul de stânga-sus al OpenStack, alegeți rl_tema_prj !!
• Ar trebui să aveți cheia publică deja importată pe rl_tema_prj (verificați!);
• Nume imagine (de selectat la Sources): RL Tema2 v2025.X (unde X e ultima revizie);
• Tip instanță: m1.small (NU aveți nevoie de mai mult, iar celelalte vor fi șterse fără notificare);
• Puneți la VM nume cu prefixul TEMA2_ (OBLIGATORIU! Altfel riscați să vă fie ștearsă) apoi username-ul vostru de Moodle (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 ;)

• Imaginea locală este acum disponibilă!
• Pentru a rula mașina virtuală a temei local, o puteți descărca de la acest URL (6GB dezarhivat).
  • Va trebui să vă autentificați cu username + parola contului de la universitate!
• VM-ul este compatibil atât cu VirtualBox (testat cu 7.1), cât și VMWare (Workstation >= 17). Pe Linux, poate fi rulat și prin qemu+kvm.
• În arhivă sunt incluse ambele proiecte ce se pot deschide cu aplicația hipervizor (.vmx pentru VMware + .vbox).
• Accesul prin ssh cu parolă (student:student) este activat, deoarece VM-ul rulează pe o rețea privată.
• Atenție: Imaginea VM-ului diferă de cea a laboratorului, asigurați-vă că îl folosiți pe cel corect (ar trebui să aveți scripturile cu t2*)!

• Înainte de a rula checkerul, se recomandă descărcarea ultimului update prin rularea:

  root@host$ t2update

Rezolvările sunt particularizate pentru fiecare student (pe baza contului Moodle). Pentru aceasta, rulați pe mașina temei comanda t2start USERNAME_MOODLE cu numele utilizatorului de Moodle ca argument.

După rulare, datele de particularizare vor fi regăsite în fişierul /root/assignment.txt de pe host. Nu modificați aceste valori, ele fiind verificate cu strictețe de către checker-ul de pe Moodle!

Ca și exemplu de pornire:

# asigurați-vă că aveți actualizat checkerul / infrastructura:
t2update
# inițializați-vă VM-ul:
t2start alex.cutarescu1337
# vedeți-vă variabilele:
cat /root/assignment.txt

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
• …

• 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 (însă veți fi notificați să re-verificați pe canalele obișnuite, forum și Teams).
  • 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 în arhiva salvată și urcată pe Moodle va fi și cel acordat în catalog la final (dacă acesta dat de ultima versiune a checkerului local și DOAR dacă nu s-a constatat că se trișează).

• 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.

• Comenzile de mai jos pot fi rulate indiferent de directorul in care ne aflăm.
• Pentru a actualiza checker-ul + alte elemente de infrastructură:

  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;

1. Pentru împachetarea soluției, rulați:

   root@host$ t2check --save

   (atenție: această comandă va reseta rețelistica și reporni toate serviciile, echivalent cu un reboot mai rapid – asigurați-vă că ați lucrat persistent (vedeți mai jos, la task-uri, cum)!)

2. Rezultatul este o arhivă semnată în directorul în care invocați comanda ($PWD).
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 JumpHost (opțiunea -J) a clientului scp pentru o conexiune directă).
4. Încărcați arhiva pe Assignment Tema 2 (Moodle).

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

Pentru configurație persistentă, atât host-ul, cât și containerele vin cu ifupdown-ng pre-instalat.

Pentru a începe să configurați, verificați fișierele existente la căile /etc/network/interfaces* (mai ales /etc/network/interfaces.d/rl.conf) ⇒ RTFM here ;).

Pentru a configura persistent rute adiționale (și nu numai!), puteți folosi hook-ul up din sintaxa de configurare interfaces. Exemplu (fragment):

iface <intf>
    address A.B.C.D/xx
    post-up ip route add X.Y.Z.T/yy via Q.W.E.R

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 într-o secțiune iface un hook ”up ip ro add invalid route…” și pe rândurile următoare aveți alte declarații, acestea nu vor mai ajunge să fie aplicate!

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

ifdown --force <intf>; ifup <intf>; ip a sh; ip ro sh
# hint: folosiți ifdown și ifup cu parametrul -a pentru a porni TOATE interfețele declarate!

Pentru a salva/restaura regulile iptables, urmați pașii de aici: https://devops.stackexchange.com/questions/11991/how-to-save-and-restore-the-iptables-rule-and-configuration-from-file (pentru iptables-restore, există mai multe modalități, e.g. puteți pune hook-uri de up la o interfață etc.). SUB NICI O FORMĂ SĂ NU INSTALAȚI PACHETELE DESCRISE DIN TUTORIALE (mai ales ifupdown – vă strică VM-ul, aveți deja ifupdown-ng!!).

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.

Este recomandat să citiți enunțul în întregime prima oară și de oricâte ori aveți întrebări!. Și, desigur, recitirea completă a task-ului următor de care vă apucați / după o pauză îndelungată de la rezolvarea acestuia.

În topologie aveți VM-ul denumit host (ce găzduiește toată infrastructura), apoi ruterele containerizate Italy, Romania și Napoli conectate toate la host; stațiile Dani și Ionut sunt conectate printr-un bridge virtual la Italy (în VLAN-ul VLAN10 – porturile sunt deja configurate pe un container-switch special); similar, ruterul Napoli este conectat tot la același bridge în VLAN6; stația Carabinieri este aflată în spatele ruterului Napoli, iar Jilava la Romania. Vedeți în topologie toate numele interfețelor virtuale pe Linux (urmează diferite tipare, e.g., to-* spre alte echipamente, port-* pentru bridge-uri, unele poartă denumiri mai unice).

Pentru a accesa un echipament, folosiți comanda de la laborator: go <Echipament> (atenție: numele este case-sensitive!). Hint: dați docker ps pentru a verifica corectitudinea pornirii VM-ului și a vedea denumirea containerelor (și eliminați prefixul mn. pentru a obține denumirea folosibilă prin go).

1. Subnetați OPTIM (i.e., VLSM) spațiul 66.$A.128.0/18 pentru strict următoarele rețele + necesar adrese asignabile (adresele la rutere și alte echipamente auxiliare sunt deja incluse în calcul):
   • rețeaua din VLAN6: $B echipamente;
   • rețeaua din VLAN10: $C echipamente;
   • rețeaua cu echipamentul Carabinieri: $D echipamente;
   • rețeaua cu echipamentul Jilava: $E echipamente;
2. Subnetați FIX (i.e., nr. rețele fixe) spațiul 10.66.$B.32/28 pentru a obține rețelele dintre ruterele (alocate fix în această ordine):
   • rețeaua dintre host și Italy;
   • rețeaua dintre host și Napoli;
   • rețeaua dintre host și Romania;
3. Configurați adresele IPv4 între TOATE echipamentele prevăzute mai sus; este OBLIGATORIU să urmați aceste convenții:
   • host va avea mereu prima adresă asignabilă (în rețeaua cu celelalte rutere);
   • echipamentele non-rutere sau rutere secundare dintr-o rețea vor începe consecutiv cu a doua adresă asignabilă, apoi a treia (dacă mai este cazul) etc.;
   • La VLAN10, ruterul (pe portul trunk al acestuia) va avea prima adresă, apoi Dani pe a doua iar Ionuț pe următoarea (ce-a de-a treia);
   • La VLAN6, Italy va deține prima adresă (fiind considerat ruterul master), apoi ce-a de-a doua atribuită lui Napoli;
4. Configurați rutarea IPv4 (default GWs și/sau rute statice) astfel încât toate stațiile să se poată accesa unele pe altele prin adresă IP!
   • folosiți CEA MAI SCURTĂ RUTĂ spre o destinație (for now)!

1. Configurați adrese IPv6 pentru toate echipamentele din rețeaua VLAN10 și VLAN6 (notă: considerați variabilele $A, $B etc. + $VLANID literal – adică le interpolați direct ca text, i.e. considerându-le ca fiind deja scrise în hexazecimale):
   • Folosiți spațiul 2025:B3F3:$B:$A:$VLANID::/112.
   • Aceeași ordine de asignare ca la IPv4.
2. Configurați conectivitate IPv6 între Italy și host:
   • Folosiți spațiul 3F66:ABBA:$C:$D::/96.
   • Prima adresă asignabilă este pentru host, a doua a lui Italy.
3. Configurați rutarea IPv6 pentru a permite comunicarea între toate sistemele cu adresă IPv6.
4. Atenție: echipamentele Carabinieri, Romania și Jilava NU vor avea adresă IPv6!

• Realizați configurațiile necesare astfel încât echipamentele să poată fi accesate prin numele lor (folosiți numele host, Italy, Napoli, Romania, Dani, Ionut, Carabinieri și Jilava - atenție la MaJuScUlE!). Adăugați intrări doar pentru adresele IPv4.

iface <intf>
	up cat /etc/hosts.orig >/etc/hosts

• Realizați configurațiile necesare pentru ca cele 7 echipamente sa aibă acces la Internet:
  • Configurați translatarea pe sistemul host astfel încât containerele să poată primi răspunsuri din Internet.
  • Configurați containerele pentru a putea accesa resurse din Internet pe baza numelor de domeniu al acestora (DNS).
  • Atenție: nu translatați orice pachet este rutat (e.g., cele între containere ar trebui să-și vadă IP-urile originale)!

• Configurați filtrarea de pachete pe rutere (alegeți echipamentul potrivit, după caz), astfel:
  • blocați pachetele telnet de la Dani și Ionut spre Carabinieri;
  • pe echipamentul Italy: blocați toate pachetele TCP + UDP pe porturile destinație 6000-7999 (trebuie să blocați atât pachetele destinate, cât și cele ce tranzitează ruterul!);
    • ca excepție, permiteți traficul de pe portul 6900 + $C!
  • blocați TOATE conexiunile spre stația Jilava, mai puțin protocoalele icmp, ssh și smtp (vor fi necesare la alte exerciții);
    1. atenție: NU blocați conexiunile inițiate de Jilava și nici răspunsurile serverelor la acestea ⇒ Folosiți reguli stateful (i.e. connection tracking)!

• Configurați reguli de DNAT pe sistemele Italy și host (după caz), astfel:
  • Conexiunile pe host la portul (18000 + $H) să conducă la conectarea pe serverul web al sistemului Romania.
  • Conectarea pe Italy la portul (8000 + $J) să conducă la conectarea la ssh-ul pe sistemul Ionut, însă DOAR DE LA SISTEMUL Jilava.
  • Sfat: aveți grijă cum testați: DNAT-ul va funcționa DOAR dacă veniți dintr-o rețea externă (e.g., un ruter din altă direcție rețelei vizate)!
• Faceți reguli de SNAT astfel încât, la conectarea (expedierea mesajelor) de pe sistemul Carabinieri către trackerele (ascunse) ale stațiilor Dani și Ionut, IP-ul sursă al cererilor să fie ascuns/înlocuit (nu contează ruterul de pe care faceți asta). NU faceți translatare de sursă la alte porturi decât cele vizate (i.e., ale trackerelor)!

• Configurați cheile publice ale utilizatorilor student de pe echipamentele Dani și Ionut, astfel încât autentificarea acestora pe contul student@Jilava să se facă fără parolă;
• Similar, faceți ca autentificarea de pe contul root@Carabinieri la root@Dani și root@Ionut să se facă cu chei publice, fără parolă!
• Folosind alias-uri SSH, configurați următoarele:
  • de pe Dani și Ionut, din contul student al fiecăruia, comanda ssh facultate să ducă către student@Jilava;
  • de pe sistemul Carabinieri, ca root, ssh dani și ssh ionut să ducă către root@Dani, respectiv root@Ionut;
  • pentru a primi punctaj, este necesară autentificarea fără parolă (i.e., primele sub-task-uri să fie făcute)!

• Creați, pe sistemul Jilava, un script: /root/scripts/request-extradition care, la rulare, trimită către polizia@Napoli câte un email (per rulare) de forma (aproximativă):

  From: admin@Jilava
  To: polizia@Napoli
  Subject: Richiesta di estradizione #<ID>
  
  Dear Carabinieri,
  
  You are kindly requested to deliver "il famoso interprete" and his brother back to us with the next available flight.
  
  We almost finished all preparations for their arrival.
  
  Regards,
  National Penitenciary Administration, Romania

  • În locul lui <ID> să fie un număr random unic fiecărei rulări!! (e.g., #61).
  • Mesajul poate fi în orice formă, atâta timp cât conține câteva fragmente din propozițiile cerute!
• Pe stația Dani, faceți un script, /root/scripts/mafia.sh, care citește și apoi șterge toate mailurile de pe sistemul Napoli și trimite reply cu subiectul Extradition request #<ID> blocked (păstrându-se ID-ul original!), iar în corpul mesajului, câte un link random de youtube, e.g.:
  • https://www.youtube.com/watch?v=3_lluKG55eU
• Pentru autentificare pe serverul de mail (atât IMAP cât și SMTP) de pe Napoli, folosiți credențialele:
  • username: polizia;
  • password: Eu;nu$d4u$Anapoi! (caracterul dolar face parte din parolă, nu denotă o variabilă, semnul exclamării de la final la fel);
• Scripturile pot fi realizate în orice limbaj de scripting e instalat pe container, însă va trebui să fie executabil direct (e.g., prin shebang și drept de execuție configurat în prealabil). De asemenea, scriptul va fi rulat din checker cu working directory necunoscut (probabil din /root, dar NU VĂ BAZAȚI PE EL!).

• Pentru ca Dani și Ionuț să aibe condiții premium de cazare, avem nevoie de următorul setup:
• Așadar, pe Jilava: realizați un script la /home/student/scripts/auto-release-albums.sh care să sincronizeze automat fișiere noi, cu următoarele caracteristici:
  • Sursă, de pe Jilava: /home/student/Music/;
  • Destinație: Italy:/var/www/export/!
  • a se păstra structura directoarelor, începând cu rădăcina (e.g., ~/Music/mafia/sa_ma_feresc.mp3 să ajungă la /var/www/export/mafia/sa_ma_feresc.mp3 pe Italy);
  • ignorați la sursă (i.e., nu copiați deloc!) fișierele ascunse (cele cu .) sau cele care conțin următoarele substring-uri în denumirea fișierului: garda, politia, cyka, salam (atât variante lower-case, cât și Capitalizate);
  • NU aveți voie să modificați ownerul/permisiunile directorului destinație (verificați-le înainte pentru a vedea cum trebuie să ajungă);
  • NU aveți parola de autentificare a utilizatorului țintă (defapt, nici nu are), dar tot trebuie să faceți ceva în această privință (i.e., să vă autentificați cu succes!)…
• Fișierele trebuie să rămână accesibile pe serverul web al Italy (http://Italy/export/…), folosiți un client HTTP în consolă pentru a testa lucrul acesta!
• Convenția de apel a scriptului (de către checker) + restricțiile sunt similare cu cele descrise în exercițiul anterior.

• Dorim să conectăm stațiile Dani, Ionut și Romania împreună printr-un tunel Wireguard pentru a securiza comunicarea!
  • Pentru adresare prin tunel, folosiți spațiul 10.$G.$H.0/29; ordinea adreselor va fi: Romania (prima), Dani (a 2-a) și Ionut (a treia);
  • Trebuie să funcționeze: trafic între toți 3 direct pe IP-ul tunelului!
  • Denumiți interfețele de tunel wg-rele pe toate containerele!
  • Tunelul wireguard trebuie să fie persistent! (folosiți hook-uri în interfaces ← recomandat / serviciu cu pornire automată, e.g., de systemd).

• Stația lui Ionut va rula un serviciu securizat pe portul UDP 1800+$J care va asculta DOAR pe adresa wireguard creată la task-ul anterior; pentru testare, aveți un server UDP, live-dedications.py, în PATH (merge pornit sub orice utilizator). Cât despre client… vă descurcați ;)
  • NU lăsați pornit acest server în timp ce rulați checkerul! Acesta își va porni singur server pe ACELAȘI port, deci va crăpa cu eroare de port deja ocupat!
• Configurați DNAT pe Romania astfel încât să poată primi conexiuni pe același port menționat mai sus, pe care să le forwardeze prin tunelul Wireguard către serviciul ce ascultă pe stația Ionut.
  • Accesul la serviciu prin Romania:1800+$J va trebui să fie funcțional din orice rețea (inclusiv Carabinieri și Jilava)!
• Restricție: este obligatoriu să folosiți DOAR iptables și/sau rutare (care ar trebui să fie deja configurată la ex. anterior) pentru a rezolva acest exercițiu, e.g., nu e voie să folosiți un serviciu auxiliar care să asculte pe un port și să redirecționeze pachetele la Ionut!
• Hint: folosiți tcpdump pentru a vedea de ce nu se întorc reply-urile ;))
• Hint2: mai trebuie niște NAT ca la task 6!