Uudised, sündmused ja blogi

Siit leiad kõik meie uudised, blogipostitused ja ürituste, hoolduste ja katkestuste informatsiooni.

Tagasi

CENTR Jamboree 14: tehniline töörühm

Jamboree teisel päeval toimusid paralleelselt 30s CENTRI tehniline ning 32ne registriteenuste töötuba. Tehnilisi igapäevaoperatsioone käsitleva töörühma kokkutulek oli seekordse Jamboree IT tehnilistest aruteludest ehk kõige "kergem", kuid eredad momendid olid siingi olemas.

Teemadeks seekord taas RIPE Atlas, Sloveenia värske registrisüsteem, e-posti autentimine, andmete kogumine DNSi põhiste turvaintidentide kohta, DNS liikluse analüüs, DNSi valideerimine ning uute TLDde kasutatavus üle erinevate protokollide ja tarkvaralahenduste.

Algatuseks aga tutvustusring, kus kõik registrid annavad kiire ülevaate, mida uut on juhtunud pärast viimast töörühma kohtumist. See on väga oluline osa kohtumisest, sest paneb kohe paika kellega vaja kindlasti esitluste vahelisel ajal aru pidada. Minu jaoks olid olulisemad uudised Sloveenia registri (ARNES) uue registrisüsteemi käivitamine, EURID (.eu haldaja) töötab oma registrisüsteemi olulise uuendamise kallal, mis peaks toodangusse jõudma sügisel, Läti register (NIC.lv) mängib erinevate uue süsteemi prototüüpidega, et leida progressiivset mudelit, millele oma uut süsteemi rajama hakata ning Kanada register (CIRA) alustas samuti registrisüsteemi ümber kirjutamist. Pole ilmselt keeruline aru saada, et ka EISis on fookus juba uue süsteemi arendusel. Teistest huvitavatest teemadest jäi kõrva Rootsi (.SE) ja Belgia (DNS Belgium) registriluku juurutamine, belglaste kaheastmelise isikutuvastuse juurutamine registripidajatele, taanlaste (DK Hostmaster) registreerija portaali arendus ning Tšehhid (CZ.NIC) sulgesid oma viimase unicast nimeserveri.

Ripe Atlase projektist olen juba kirjutanud (http://internet.ee/et/eis/blogi/icann-49-tehniline-paev/). Suurt uudist siin polnud. Meeldetuletuseks, et tegemist on healoomulise botnetiga, mille eesmärk on pakkuda taristut DNSi alasteks uuringuteks, mõõtmisteks ja testimisteks. DNSi operaatoritele annab see võimaluse vaadata oma võrku väljaspoolt ning testida selle kättesaadavust ja side kvaliteeti väga erinevatest punktidest üle terve maailma. Võrgus on täna üle 6000 mõõtmispunkti. Sondides kasutatava tarkvara lähtekood on nüüd avatud, täiendatud on APIsid ja lihtsam on liidestada süsteemi montitooringutarkvaraga nagu Nagios.

Minu jaoks enim oodatud esitlus tuli järgmisena - Sloveenia (.si) registri (ARNES) esitlus selle aasta märtsist käivitatud uuest registrisüsteemist. Projekti "kevadpuhastus" käigus vahetati välja seni kasutataud 8 aastat vana süsteem, mis oli ehitatud järgides selle aja IETFi standardi kavandeid ja ei vastanud RFCdele. Arendus võttis aega 2 aastat ning ühes süsteemiarendusega vaadati üle ka kõik protseduurid. Põhilised muudatused seisnesidki vastavusega hetkel kehtivatele RFCdele EPP osas, REST liidese lisamises, loomulikult lisati ka kõik uued muud moodulid. Andmebaasimootorina võeti kasutusele MySQL 4 asemel, selle derivaat Mariadb 5.5. Lisandus ka nö registripidaja portaal. Süsteem ise kirjutati Javas. Kokkuvõttes oli register ise süsteemi käivitumisega rahul. Esinesid mõned vead ja probleemid - 3 garantiinis olnud domeeni kustusid registrist, registreerija vahetusel kasutatavad kinnituse e-kirjad ei läinud välja, probleeme oli süsteemi teadete (poll) edastamisega, aeglase ajaloo kuvamisega ja veel mõned lahendamist vajavad küsimused, kuid registri enda hinnangul mitte midagi hirmsat. Mis puudutab registripidajaid, siis enamus alustas oma süsteemide testimist alles 2 nädalat enne välja kuulutatud uue süsteemi käivitamise tähtaega, mis tähendas, et hulk, umbes sajast registripidajast, ei olnud vahetuse hetkel valmis ja see omakorda lisas veel mõned murekohad registreerijate jaoks. Parandada ja arendada on veel vaja registripidajate vaheline võtme vahetuse protsess DNSSECi tarvis (DNSSEC keyrelay). Sain nii mõnegi mõtte kuidas meiegi üleminekut uuele süsteemile sujuvamaks ja loodetavasti vähem probleemsemaks muuta.

Erwin Lansing Taani registrist (DK Hostmaster) tegi ettekande e-kirjade kaitsmisest DMARC (Domain-based Message Authentication, Reporting and Conformance)autentimise meetodiga. Üldtuntud on fakt, et e-kirja saatja reale võib igaüks suurema vaevata kirjutada mida iganes. See on hea võimalus rämpsposti saatjatele, ilmselge vahend identiteedivarguste puhul jne. Lahendusi on läbi aegade välja pakutud mitmeid. Täna on neist tuntuimad SPF (Sender Policy Framework) ja DKIM (DomainKeys Identified Mail). Mõlemad tegelevad e-posti autentimisega, kuid erinevalt. Esimene on rajapõhine - kontrollitakse, kas kiri saadeti teele domeeni omaniku poolt lubatud serverist. Teine on sisupõhine, toetudes allkirja loogikale. Metoodikad täiendavad teineteist ning DMARC toobki need tehnoloogiad kokku, lisades võimaluse saatjatel saada tagasisidet e-posti saaja saabuva e-kirja töötlemise viiside kohta ning võimaluse domeeni omanikul määrata, kuidas saaja peaks käituma epostiga, mis ei läbi DMARCi kontrolle. Kuid nagu ikka, on sellel lahendusel veel mõned lahendamata puudused. Nimelt, ei jõua kirjad saatjalt vastuvõtjale tihti otse - edasisaatjad, e-posti loendid, spämmifiltrid jne. Seetõttu on suure valepostiivse ohu tõttu riskantne kasutada 'reject' poliitikat kontrolli negatiivse tulemuse korral. Siiski on mitmed suurkoproratsioonid nagu Google, Twitter, PayPal ja Microsoft andnud teada suurepärastastest tulemustest DMARCiga näiteks õngitsemise tüüpi rünnete ennetamisel.

Stéphane Bortzmeyer AFNICist esitles ettepanekut moodustada keskne andmebaas, kuhu reaalajas koguda päringu teostaja seisukohast anonümiseeritud DNS päringu- ja vastuspakettide andmeid. Täna pole siuliselt võimalik saada ajakohast ja täpset infot DNSi intsidentide kohta. Andmete abil saaks kogukond paremat ja täpset teavet rünnete ja probleemide kohta, vajadusel toetada ohvrit ja töötada välja lahendusi sarnaste olukordade edaspidiseks vältimiseks. Lahtine on see, kes peaks seda andmebaasi haldama - ICANN, DNS-OARC või mingi kolmas valdkonna oraganisatsioon.

Järgmiseks anti ülevaade Apache Hadoop ja Hive töövahenditest, mis sobivad väga hästi suurte andmehulkade analüüsiks - DNSi puhul siis PCAP failide analüüsiks. Poola register NASK kasutab neid vahendeid oma igapäevatöös ja on rahul. Nimeserveripäringuid säilitavad poolakad 30 päeva ja vastuspakette 10 päeva.

Samal teemal jätkates tutvustas Šveitsi registri (SWITCH) juures tegutsev CERT, kuidas ja milleks nemad DNS andmeid kasutavad. PCAP failide analüüsiks kasutatakse Rootsi registri (.SE) arendatud PacketQ tarkvara. Lahendust kasutatakse Šveitsi (.ch) tsoonis asuvate domeenide kohta valeandmeid edastavate nimeserverite ning Šveitsi ettevõtteid puudutavate õngitsemisega tegelevate lehtede otsimiseks. Esimeste puhul seisneb protseduur väljaspool Šveitsi asuvate lahendavate nimeserverite nimistu koostamises, mis reastatakse vastavalt päringute arvule populaarsemate domeeninimede kohta. Siis otsitakse esimese 30000 hulgast välja avatud nimeserverid ning kontrollitakse, kuidas need vastavad hästi tuntud (näiteks viirusetõrjega seotud) domeeninimede päringutele. Õngitsejate tuvastamiseks reastatakse päringud, mis sisaldavad kaubamärke, jäetakse välja 2. taseme domeenid ja NXDOMAIN kirjed ning järele jäänud nimistust otsitakse vastu sama kaubamärkide loendist enam kui 4 päringuga domeeninimed ning väljastatakse hoiatus. Igati hea näide, kuidas ka domeenihaldurid, kas ise või pigem koostöös näiteks kohaliku CERTIga, saavad kaasa aidata võitluses kübermaailma tumedama poolega.

Enne lõppu tegi Patrick Wallström Rootsi registrist (.SE) arendustöögrupi hõngulise ettekande uuest töös olevast tsooni testimise vahendist Zonemaster. Praegu kasutatakse selleks enamasti rootslaste enda arendatud vahendit DNSCheck või Prantsuse registri (Afnic) arendatud lahendust ZoneCheck. Prantslased on oma vahendi toetamise juba lõpetanud ja et ka rootslased tundisd, et on vaja midagi paremat, ühendati jõud. Sündis idee uue vahendi arendamiseks, mis ühendaks mõlema senise tööriista parimad omadused. Põhilised testid, mida selliste vahenditega tehakse, on lisaks tsoonifaili struktuurile, delegeerimise testid - kas nimeserverid on määratud, kas nimeserverid vastavad, kas IP aadressid ja domeeninimed vastavad nõuetele, aga ka näiteks DNSSECi parameetrid nagu kasutatud algoritmid ning usaldusahela terviklikkus. Lahendust kirjutatakse Perlis, beta versiooni on oodata septermbris ja esimest versiooni juba oktoobris sel aastal.

Ning viimasena tutvustas Ed Lewis ICANNist nende, minu arvates veidi hiljaks jäänud initsiatiivi TLD Universal Acceptance, mis tegeleb sellega, et hulgaliselt juurde tulevate uute tippdomeenidega saaks ka reaalselt midagi teha. Milles probleem? Tippdomeenide nimekiri on olnud väga pikka aega üsna muutumatu. See tähendab, et paljud tarkvaralahendused, näiteks spämmifiltrid, aga ka sirvikud, lähtuvad koodi kirjutatud konstantsest nimistust korrektsete domeenide tuvastamisel. Lisaks on juba mõnda aega tehtud kõvasti tööd IDN domeenidega ehk Eesti mõistes täpitähti sisaldavate 2. ja madalama astme domeenidega, mis senini väga hästi ei toimi, sest e-posti ja ka veebisirvikute tugi sellistele domeenidele on endiselt nõrk. Nüüd, aga tulevad peale ka IDN tippdomeenid. Probleem on ka selles, kuidas otsimootorid otsingut tõlgendavad - kuidas saada uues tuhandete tippdomeenidega maailmas aru, mida kasutaja täpselt tahab, kas otsitakse konkreetset domeeni või vastuseid märksõnale olenemata tippdomeenist? Initsiatiiv on olemas, tarkvara tootjatega suhtlus käib ja ehk saame selle tulemusena ka meie tulevikus mugavamalt täpilisi domeene oma .ee tsoonis kasutada.

Ürituse lõpetas arutelu IANA nõudest tsooni delegeerimiseks vajalike nimeserverite arvu kohta. Täna nõutakse minimaalselt kaht nimeserveri IPd. Aga nagu alguses juba mainitud, siis Tšehhi register sulges oma viimase unicast autoriteetse nimeserveri ja järgi jäi üks anycast nimeserverite pilv, kus nimeservereid palju, kuid kõik vastavad ühele IP-le. Nii tõstatasidki tšehhid küsimuse, kas on ehk aeg see reegel üle vaadata? Tõesti, unicast ehk ühe masina nimeservereid jääb üha vähemaks ning anycasti pilved tungivad peale. Mingit otsust selle kohapealt see töögrupp teha ei saanud, kuid küsimus on õhus ja sisuliselt õige.

Päevakava ja osad presentatsioonid on leitavad CENTRi kodulehelt https://centr.org/Tech30. Järgmine tehnilise töögrupi kohtumine toimub 2 novembril.

Kommentaarid

105.02.2021

555

105.02.2021

555

105.02.2021

555

105.02.2021

555

105.02.2021

555

Email again:

Veel uudiseid, sündmusi ja blogipostitusi