Vorgurakendused 2 prax 1 2015

Allikas: Lambda
Redaktsioon seisuga 3. september 2015, kell 07:36 kasutajalt PriitJ (arutelu | kaastöö)
Mine navigeerimisribale Mine otsikasti

Zombie robot attack

P2MD5 - P2P MD5 cracker

Ülesandeks on ehitada P2P rakendus MD5 hashi murdmise ülesande tükkide jagamiseks võõrastele masinatele ja rehkendustulemuste kättesaamiseks, mis teeb laviinitaolise otsingu mööda P2MD5 klient/servereid, isetehtud P2P mehhanismi abil.

Kasutajaliidese hea kvaliteet ei ole praksis oluline.

Huvi korral võid vaadata ka sarnaseid vanu ülesandeid 2013 aasta arhiivis, 2014 aasta arhiivis ning sealt edasi vanemaid.

HETKEL KIRJELDUS POOLIK, eriti protokolli osa

Üldkirjeldus

P2MD5 võimaldab:

  • saata teistele P2P masinatele MD5 bruteforcemise ülesande juppe
  • saada tagasi rehkendatud tulemus.


Võõraste rehkendamiseks valmis masinate leidmiseks kasutab P2Net järgmist viisi:

  • Saadab tema oma masinas oleva faili machines.txt masinatele ressursipäringu. machines.txt sees on masinate ip ja pordid json listina kujul
[["11.22.33.44","2345"],...,["111.222.333.444","23456"]]


  • Ressursipäringu kättesaaja otsustab, kas tal on ressurssi rehkendada. Kui jah, saadab ta OK teate ressursipäringu algatajale. Igal juhul saadab ta ressursipäringu P2P võrku edasi, vähendades time-to-live numbrit. Ehk, masinad saadavad minu antud päringut rekursiivselt ise edasi.

N sekundit peale ressursipäringu tegemist (N sea algul näiteks paari sekundi peale) jaotab ressursipäringu tegija ülesande talle OK vastanud masinate vahel ära. Edaspidiseid OK teateid ta ignoreerib (elegantsem oleks vastata, et ei kasuta).

  • Seejärel saadab ta kõigile OK vastanud masinatele ülesandesõnumi, mis sisaldab md5 hash stringi ja vahemikku katsetatavast sõnalistist.
  • Kui mingi masin saab minu ülesandesõnumi kätte, siis ta hakkab seda tükki läbi analüüsima ja saadab tulemuse päringu algatanud masinasse: tulemus ütleb kas et ei leidnud või et leidsin konkreetse sobiva stringi, ja mis string see on.


Miks just selline päringu edasisaatmisviis?

Põhimõtteliselt saab päringut massidesse P2P meetoditega laiali saata kahel viisil:

  • Iteratiivne meetod (antud praksis seda ei kasuta): algne masin küsib tuttavatelt neile tuttavate masinate faile, ja suurendab seeläbi endale teadaolevate masinate hulka. Igalt uuelt teadasaadud masinalt küsib ta jälle selle masina tuttavate faile jne. Teised masinad algset päringut ise kuhugi edasi ei saada. Meetodi pluss on see, et algne masin saab lihtsalt tagada, et päringut ei saadetaks kaks korda samale masinale. Meetodi miinus on see, et kõik masinad võrgus saadavad lõpuks terve neile tuttavate masinate faili algsele masinale: see tähendab väga suurt hulka väga suurte failide saatmisi, mis hakkavad jõhkralt ummistama võrku, ja algse masina väike kanal tõenäoliselt ummistub varsti. Saadud failide ühisosad on väga suured. Halvemal juhul saab algne masin N identset sõnumit, kus igaühes on N ip-d, kus N on kõigi masinate arv, kus jookseb P2Net.
  • Rekursiivne meetod (antud praksis nõutud): algne masin saadab oma päringu tuttavatele masinatele, kes selle omakorda enda tuttavatele edasi saadavad jne. Igüks, kes leiab enda failide hulgast vajaliku faili, saadab info algsele masinale (vastasel korral ei saada ta algsele masinale midagi). Algne masin ei suurenda endale teadaolevate masinate hulka. Meetodi pluss on see, et algsele masinale saadetakse tagasi infot ainult siis, kui vajalik info leitakse (väga väike protsent masinaid) ja see info on lühike. Koormus võrgule langeb tugevasti ja algse masina kanal tõenäoliselt ei ummistu. Meetodi miinus on asjaolu, et üks ja sama masin võib saada algse päringu mitu korda eri suundadest, mis jällegi kasvatab võrgu koormust. Seda viimast probleemi saab mitmel moel leevendada (kuigi mitte täielikult kaotada), eeskätt päringu ttl (time to live) parameetrit kasutades, päringu ahela masinate lisamises päringu parameetrite hulka jne.

Gnutella kasutab rekursiivset meetodit, nii ka meie P2Net. Lihtsakoeline rekursiivne meetod ummistab suure klientide arvu korral võrgu ja sele asemel kasutavad suured P2P süsteemid kas:

  • struktureeritud nn superpeeride süsteemi a la Kazaa ja esialgne Skype, kus rekursiivne päring toimub ainult superpeeride vahel, ja neid on vähe, või
  • väga kavalat nn distributed hash tables (DHT) mehhanismi, a la freenet ja (osaliselt) bittorrent. DHT on üks mitmest bittorrenti poolt kasutatud meetodist, kuigi bittorrenti põhifookus on hoopis faili paralleelse allatõmbamise optimeerimisel mitme masina koostöös, mitte masinate/failide leidmisel. Või:
  • kasutavad masinate leidmiseks eeskätt tsentraalseid servereid, a la esialgne Napster või kaasaegne Skype

Tehnilised nõuded

Programmeerimiskeele ja muu tehnoloogia valik on vaba, kuid rakendus peab vastama neile tingimustele:

  • Kogu programm peab töötama kas ITC-maja klassi arvutis või sinu oma läptopis, mis ITC maja klassis kaasas. Mingit kaugel asuvat serverit põhirakenduse jaoks kasutada ei tohi. Arusaadavalt võib aga panna P2Net lisaks käima ka suvalistesse välistesse masinatesse.
  • Http protokolli jms realisatsioon peab olema teie oma programmi osa, mingit "suurt" http serverit a la apache kasutada ei või. Kõikvõimalike võrguteekide (versus eraldiseisvad veebiserverid) kasutamine on ok, mikroserverite koodi integreerimine oma programmi on ok.

Protokoll

Kõik sõnumid saadetakse http kaudu. Neid sõnumeid saab katsetada brauserist ja curliga jne.

Ressursipäringu saatmine ja edasisaatmine

Konkreetsele masinale 11.22.33.44 (kus P2Net jookseb pordis 2345) ressursipäringu saatmine http://11.22.33.44:2345/resource?sendip=55.66.77.88&sendport=6788&ttl=5&id=wqeqwe23&noask=11.22.33.44_345&noask=111.222.333.444_223

kus parameetritel on järgmine sisu:

  • resource: ütleb, et tegu ressursipäringuga
  • sendip: esialgse saatja ip
  • sendport: esialgse saatja port
  • ttl: kui mitu otsingu-hopi veel teha (iga edasiküsimine vähendab ühe võrra)
  • id: optsionaalne päringu identifikaator
  • noask: (optsionaalne ja võib korduda) list ip_port kombinatsioonidest, kellele pole mõtet edastada (eraldajaks alakriips)

Päringu identifikaator ei pea tingimata üle terve võrgu unikaalne olema - lihtsam on ja ajab asja ära, kui on saatva masina piires unikaalne.

GET-päringu vastuseks on õnnestunud päringu korral number 0, ebaõnnestunud päringu korral muu (vea)number. Vastuse mõte on eeskätt debugimise lihtsustamine ja vastust peaks pärija üldiselt ignoreerima. P2Net peaks töötama edukalt ka juhul, kui ta saatmise peale ühenduse lihtsalt kinni paneb ja vastust kuulama ei hakka.

P2Net-le tulnud päringu edasisaatmine käib täpselt sama protokolliga, kuid edasi saadetakse veidi muudetud päring:

  • ttl vähendatakse ühe võrra
  • optionaalselt: lisatakse oma masina ip uue noask argumendina

Seejuures ei saadeta päringut edasi, kui sissetulnud ttl oli 1 või vähem (st ttl=0 päringuid enam kuhugi ei saadeta)

Seda päringut saab ka brauserist katsetada, kuigi brauser ei saa vastuseks midagi huvitavat peale debugimis-vastuse 0 või mingi veakoodi.

Klientide filtreerimine (juhul kui soovitakse juhtida mingit alamhulka masinatest) toimub programmi käsurea kaudu. See osa ei ole kohustuslik vaid tuleneb konkreetsest rakendusest; protokollis see funktsionaalsus ei sisaldu.

Tulemuse tagastamine algsele pärijale

Vastus oleks http post meetodiga käivitatud programmi kogu väljundi saatmine algsele küsijale muutmata kujul koos lisainfoga 

http://11.22.33.44:2345/result

POST-itatud data: 

  {"sendip": "55.66.77.88", 
    "sendport": "6788",
    "id": "asasasas",
    "encoding": "ascii" või "base64",	  
    "content": "failisisustring"}

id peaks vastama esialgse saatja antud id-le, juhul kui seda kasutatakse.

  • id: esialgse päringu id (kui oli algselt antud)
  • content: käsureaprogrammi väljund (kui ei ole plaintext, peaks olema base64-encodetud)
  • encoding: mis formaadis content on
  • sendip: tulemuse saatnud masina ip
  • sendport: tulemuse saatnud masina port

Programm võiks ka mitte crashida, kui id puudu on, kuna id on optional (aga praktiline ja mõtekas on lisada).

Postituse saaja vastab eduka kättesaamise korral arvu 0, arusaamatuste korral mõne muu (vea) numbri. Jällegi, vastuse mõte on eeskätt debugimise lihtsustamine ja vastust peaks pärija üldiselt ignoreerima. P2Net peaks töötama edukalt ka juhul, kui ta saatmise peale ühenduse lihtsalt kinni paneb ja vastust kuulama ei hakka.

Praksi kaks osa

Väga soovitav on teha praks kahes osas ja esitada kaks korda ülevaatamiseks:

  • Teha http protokolli järgida suutev esmane rakendus.
  • Lisada sinna kogu vajalik funktsionaalsus:
    • Ressursipärinngu protokolli implementatsioon
    • Ülesande splittimine ja laialisaatmine
    • Saadud MD5 bruteforcemise ülesande lahendamine ja vastamine
    • Vastuste kokkukogumine ja puuduolevate vastuste ülesandejuppide uuesti laialijagamine

Http protokolli järgimise võimet kontrollitakse praksi eduka läbimise tingimusena.

Soovitusi ja ideid

Arendamiseks ja testimiseks pead saama jooksutada oma masinas mitut erinevat koopiat omaenda P2Net-st, igaüks oma pordil, igaühel oma konfifail tuttavate masinatega.

Hea mõte on teha P2Net käsurealt käivitavaks nii, et ta võtab kohe käsurealt pordinumbri parameetriks ning loeb siis oma konfifaili vastavast pordinumbrist tuletatud failipathist.

P2Net peab päris kindlasti sisaldama või kasutama http serverit, muidu ei ole temaga võimalik väljast ühendust võtta. NB! See ei tähenda mingit nö suurt veebiserverit a la apache, vaid pigem ise kirjutatud väikest minimaalset serverit, mis pealegi ei pea veebilehti serveerima ja cgi-sid käivitama, vaid ainult teatud käskudele/parameetritele reageerima.

Server tuleb realiseerida ise, kasutades võrgust leitavaid näiteid mikro-http-serveri jaoks (tüüpiliselt paar lehekülge koodi). Selliseid näitekoode võib täiesti otse kasutada.

C jaoks on sobiv mikroserver näiteks tiny, java jaoks on see server väga hea väike näide, aga selgitava tekstita, ning selgitavate tekstidega servereid leiad mh siit ja siit.Loe java socketitest põhjalikumalt siit. Pythoni serverinäite saad siit. Http kohta võib lugeda näiteks siit.

Kasutajaliides võib olla tehtud aknaga, aga see ei ole kohustuslik: võib teha ka puhtalt käsurea rakenduse.

Rakendus on mõistlik teha nii, et annad käivitamisel ette pordi, millel ta räägib, ning kui seda porti ei ole antud, siis kasutad vaikimisi porti 1215 (1214 on Kazaa port).

Häid selgeid näiteid ja õpetusi socketite ja serveri tegemise kohta leiad veel siit:

Firewall ja NAT

Firewallist läbi murdmise ja kinniste portidega ühendamise probleemiga ei pea selles praksis tegelema. Samas tähendab see, et ei ole kuigi lihtne teise masinaga tegelikult ühendust saada (ühes masinas debugimise võimaldamine ongi seepärast kriitiline).

Kes P2Net käima saab, võib mõelda välja ja realiseerida probleemi lahendamiseks sobiva vaheserveri: selle eest saab ekstrapunkte.

Võrgust infot otsides leiad kahte liiki teemasid, meie jaoks oluline on siit listist teine:

NB! Seda kõike ei ole väga lihtne teha ja sinu P2Net (ja ka selle inimese P2Net, kellega suhtled) peab ka oskama seda vaheserverit kasutada. Ära hakka seda ehitama, kui nö lihtne P2Net veel ei tööta!

Ekstra-lisapunktide saamise variant: realiseeri ja pane kõigile kasutatavaks firewalliprobleemi lahendamiseks sobiv vaheserver. Kirjuta kasutamise juhend ja näited, mida teised saaks soovi korral oma P2Net jaoks tarvitada (st panna nad sinu vaheserverit kasutama, nii et seda saaks ka arvutiklassist kasutada). Esimesed kaks gruppi, kes sellega hakkama saavad, saavad lisaks pooled praksipunktid!


Punktiarvestusest

Kui P2Net protokoll töötab vastu mõne teise grupi P2Net-i, sellele on realiseeritud mingi rakendus ja koodi suudetakse seletada, saab täispunktid.

Kui teiste P2Net-programmidega ei suuda suhelda, aga iseenda koopiatega siiski, siis päris täispunkte ei saa.

Pärit leheküljelt "http://www.lambda.ee/w/index.php?title=Vorgurakendused_2_prax_1_2015&oldid=12528"