Kuuldused e-posti surmast on jätkuvalt liialdatud

E-post võis küll hiljuti tähistada oma 47. sünnipäeva, kuid pakub jätkuvalt uusi rakendusi ning väljakutseid.

Sõltumata regulaarsetest uutest e-posti killeritest on e-post, nagu me seda tunneme, püsinud enam-vähem samasugusena juba aastakümneid. Loomulikult on juurde tulnud uusi võimalusi nagu näiteks manuste kasutamine või täpitähtede tugi, mida e-posti esimesed versioonid sugugi ei tunnistanud, kuid see on reeglina alati olnud olemasoleva lahenduse raamides toimetamine, mitte millegi päriselt uue lisamine (manusega kiri oleks täiesti loetav ka manuse-eelse ajastu e-posti kliendiga, see lihtsalt näeks kummaline välja). Samal ajal on Google Wave, Slack, Facebook, WhatsApp ja teised e-posti alternatiivid lisanud loetamatul hulgal täiendusi, nii kasutajakogemuse kui turvalisuse vallas, mida e-postis kas senini ei ole või ei saagi kunagi olema.

E-posti areng on väljastpoolt vaadates kohutavalt aeglane, viimaste aastate suurim täiendus e-posti standardites on olnud täpitähtede tugi e-posti aadressi kasutajanime osas (domeeni osas olid täpitähed juba varem lubatud), näiteks андрис@уайлддак.орг on nende uuenduste alusel täiesti korrektne ja toimiv aadress. Samas suurem osa e-posti servereid selliseid aadresse endiselt ei toeta, kuna vastav standard on “alles” 6 aastat vana.

E-post elab ikka veel

Miskipärast ei ole e-posti kasutamine, hoolimata selle piiratud võimalustest ja üliaeglasest muutumisest kuhugi kadunud – vastupidi, selle tähtsus on ajas aina kasvanud. Tõsi, korrespondentsi laad ei ole võibolla püsinud päris sama. Täna me ei leia oma e-postkastist mitte niivõrd otsesuhtlust oma sõprade või lähedastega (selle jaoks on välksuhtlusrakendused tõesti paremad), vaid uudiskirju, paroolimeeldetuletusi, elektrooniliste teenuste kviitungeid, kõikvõimalikke teavitusi, tuttavate tehtud fotosid ühistest üritustest jmt.

Lisaks muutunud sisule on e-postkast sarnaselt päris postkastiga muutunud rohkem globaalse identiteedi osaks, selmet olla vaid suhtluskanal – Jaan Tammesid võib olla maailmas palju, aga konkreetsel aadressil elab siiski neist vaid üks. Facebookis on samanimelisi inimesi palju, aga igaühel neist on unikaalne e-posti aadress. E-posti aadress on seega sarnane läänemaailma kurikuulsate gaasiarvetega, mida tahetakse pangakonto avamisel näha. Kuigi e-post pole selleks üldse mõeldud ja riiklikult täiesti sanktsioneerimata, on praktikas tegu identiteedi tunnusega.

Failisüsteemi rõõmud ja mured

Muutunud sisu on jätnud oma jälje ka kasutaja e-postkasti majutavale ressursile. Uudiskirja peen HTML kood ja kujundus on mahult hoopis erinev välkteatest sõbrale. Kirjade kustutamise asemel kuhjatakse need erinevatesse kaustadesse, nii et mõnes kaustas on varasema 200 asemel 200 000 kirja. Moodsa telefoniga saadetud foto on suurem, kui kunagi ammu olid mitme aasta kirjad kokku. Mis siis veel sellest rääkida, kui see foto saadetakse mitte ühele inimesele, vaid kõikidele samal üritusel viibinutele. Mäletan isegi kuidas kunagises töökohas saatis postiserveri administraator kõigile kurja kirja, kui inimesed töökaaslastele ühte ja sedasama koerapilti edastasid ning sellega serveri töövõime ohtu seadsid.

Samas, kui nüüd vaadata, et kuidas on e-posti serveri tarkvara (eelkõige pean silmas kõigile kättesaadavat avatud lähtekoodil põhinevat tarkvara) nende muutustega kaasas käinud, siis selgub, et väga nagu ei olegi. Riistvara on odavam ja kiirem kui varem, seega piisab reeglina lihtsalt tarkvara seadistuses määrata endise 10MB postkasti suuruse asemel 10GB ning ongi nagu kõik korras. Enamikel juhtudel ongi korras, kümne inimese 10GB postkastide jaoks läheb serveris vaja kuni 100GB kõvaketast, mis ei ole tänapäeval mingi suurus. Probleemid tekivad siis, kui tegu on juba suurema hulga kui toatäie inimeste postkastide majutamisega. 1000 inimese postkastide majutamiseks läheb vaja 10TB kõvakettaruumi, 10 000 inimese jaoks juba 100TB jne.

Reeglina ei ole inimestel postkast kogu aeg servani täis, mis annab mõningase võimaluse paigutada serverisse rohkem postkaste, kui sinna tegelikult mahuks. Samas aga tähendab see pidevat monitoorimist, et kui täis või tühi mingi server tegelikult on ja vajadusel migreerida kasutajaid, tuleb liigutada suuri postkaste tühjematesse serverisse ja teha muid sarnaseid tegevusi. Klassikaliselt asuvad kasutaja kõik kirjad kas ühesainsas failis (mbox formaat) või ühes kaustas (maildir formaat), igal juhul tähendab kasutaja migreerimine, et ümber ei tule kolida mitte neid kirju, mis serverisse ära ei mahu, vaid terve postkast koos saba ja sarvedega.

Mõningase leevenduse annavad teinekord skaleeruvad võrgupõhised failisüsteemid nagu GlusterFS, kuid sõltuvalt kasutatud tarkvarast võib tekkida ootamatuid ja seletamatuid probleeme – tarkvara eeldab failisüsteemilt reeglina sellist käitumist, milleks võrgupõhine kuidagi võimeline pole, st. et süsteem peaks olema korraga kiire ja usaldusväärne. Failisüsteemi toimingud (näiteks faili ümbernimetamine, mis on maildir puhul väga tüüpiline tegevus) teostatakse koheselt ja enam-vähem konstantse kiirusega ning üldiselt need toimingud ka õnnestuvad, võrk aga on tunduvalt ebakindlam. Tavaliselt kõik toimib, aga siis, ühel hetkel, võtab faili ümbernimetamine aega 10 sekundit. Iseenesest mis siis sellest, aga kui tavaliselt võib lugeda sellise tegevuse kestust pigem milli- või isegi mikrosekundites, siis 10 sekundit on sellest 10 000 korda aeglasem. Lisame patta veel samal ajal kuhjuvad muud ootel tegevused (ka kõik ülejäänud kasutajad tahavad samal ajal oma postkastis muudatusi teha) ja saamegi tulemuseks väikese kaose.

Üks häda ja viletsus

IMAP protokoll, mille abil kasutajad oma e-kirju serverist alla laevad, on algselt disainitud olema skaleeruv, kus eeldatakse, et kasutaja võib ühenduda korraga erinevate serverite pihta kuna e-posti server ei pea otseselt olema seotud kirjade hoiustamisega. Selline disain tuli reaktsioonina ülimalt piiratud POP3 protokollile, kus, vähe sellest, et ei saa sama kasutaja paralleelselt pöörduda erinevate serverite poole, ei saa kasutaja paralleelselt üldse midagi teha ning peab piirduma üheainsa ühendusega. Samas praegused IMAP implementatsioonid on tavaliselt jäigalt failisüsteemiga seotud ja nendes implementatsioonides ei saa kasutaja päringuid hajutada, kuigi protokoll seda isegi võimaldaks. Ka Dovecot Director puhul, mis on kättesaadavatest lahendustest senini parim, satuvad sama kasutaja paralleelsed ühendused alati samasse serverisse (kuigi tõsi, see server võib aja jooksul vahelduda).

Veel üks keeruline küsimus e-posti puhul on autentimine. Esiteks on autenditavaid kohti palju – veebimeil, IMAP, POP3, SMTP ning kõiki neid tuleks kuidagi eraldi kohelda. Kui me tahame pakkuda veel kahefaktorilist autentimist, rakendusepõhiseid paroole, autentimislogi, ajas uuenevat parooliräsi algoritmi jmt. siis, kuigi võimalik, tähendab see olemasolevate rakenduste korralikku häkkimist.

Meilirakenduste monitoorimine on samuti olnud üldiselt paras peavalu. Loomulikult on olemas kõiksugu tööriistad e-posti järjekordade haldamiseks, kuid suures osas tähendab see failisüsteemis perioodilist failide ülelugemist või paremal juhul meiliserveri logifailide analüüsimist. Tõenäoliselt jääb meile meiliserveri kõhus toimuv siiski parajaks mustaks auguks. Siin tuleb jälle mängu sama kana ja muna probleem, et meilisüsteem asub reeglina ainult ühes masinas. Sellises seadistuses on ühes masinas loomulikult ka logifailid ja seega, kuigi võib-olla ebamugav, on neid logifaile võimalik töödelda standardsete utiliitidega nagu grep, awk ja sõbrad. Jaotame aga meilinduse mitmesse serverisse laiali ja kohe ongi pilt eest läinud, et mis täpselt toimub.

Üks tüüpiline puudujääk e-posti serverite tarkvaras on muutuste jälgimine kasutaja kontol. Näiteks kui kasutaja loob ühes meilirakenduses IMAP protokolli kaudu uue kausta, või veel hullem – nimetab mõne olemasoleva kausta ümber, siis sama kasutaja teine seade ei saa sellest mitte kuidagi teada. Muutused kaustadega ilmnevad üsna pea, sest reeglina teevad meilikliendid peale uue ühenduse avamist kaustade listingu, kuid esiteks võtab see aega ning teiseks, ümbernimetamiste puhul see ei aita, meilikliendi jaoks paistab selline kaust olevat uus kaust uute kirjadega, mis tuleb jälle alla tõmmata, samas kui ümbernimetatud kaust koos selles olnud kirjadega kustutatakse ära. Hea küll, IMAP klient on piiratud kasutatava protokolliga, aga sama kandub üle ka veebimeili rakendustele, mis reeglina on samuti taustal IMAP kliendid.

Ning kui veebimeil juba jutuks tuli, siis veebimeil üle IMAP protokolli on paras kaos. Heal juhul istub veebimeili rakenduse ja IMAP serveri vahel mingisugune kolmas rakendus, mis hoiab ühendusi IMAP serveri suunas lahti, aga reeglina tähendab siiski iga uus päring kliendi poolelt kogu IMAP tsirkuse taasmängimist – ühenduse avamine (sh. TLS “käepigistus”), serveri võimaluste küsimine, kasutaja autentimine, kausta avamist ning alles seejärel toimingut kirjaga (näiteks selle loetuks märkimist). IMAP protokolli kasutamine ning RFC822 vormingus e-kirjade haldamine teeb veebimeili arenduse ülimalt keerukaks ja aeganõudvaks. Populaarse veebimeili tarkvara Roundcube uue versiooni arenduseks mõeldud rahakogumise kampaania lõppes edukalt juba 3 aastat tagasi, aga siiani peame leppima vana versiooni kasutamisega.

Mida siis teha?

Väikestel pakkujatel taolisi skaleeruvusprobleeme, kus kasutajad enam ühte või paari serverisse ära ei mahu, üldiselt ei ole ning nemad saavad vabavara peal hakkama. Suured e-posti teenuse pakkujad on lahendanud skaleeruvusprobleemid ennekõike omaenda vajadustele vastava tarkvara arendusega, kus failisüsteemi asemel on kohe kasutuses skaleeruvad võrgusüsteemid ning tarkvara ei oota failisüsteemi tavapäraseid garantiisid, kuid need ei ole siis enam vabavaralised lahendused. Zone, kus postkastide arvu loetakse kuuekohalise numbriga, on selles suhtes olnud veidi õnnetus positsioonis, et tegu ei ole ammu enam väikese pakkujaga, aga maailma mastaabis ka mitte suurega. Olemasolevad vabavaralised lahendused jäävad kitsaks, kuid suurte poolt kasutatavad e-posti lahendused jäävad käeulatusest välja. Ainus mõeldav variant kuni senimaani oleks olnud Dovecoti kommertslahendus koos Dovecoti Directori ning object storagega.

Zones läksime siiski teist teed ning ka meil on nüüd kasutusel maja sees ehitatud (kuid siiski vabavaraline) e-posti süsteem, mis vastab paremini reaalsetele nõudmistele.

Featuuridest, seekord positiivse noodiga

Kirju ei hoita enam failisüsteemis, vaid need on laiali suures MongoDB sharditud klastris. See tähendab, et kui kasutaja rakendus teeb kirjade listingut, siis osad kirjad sellest listingust võivad asuda ühes, aga osad hoopis teises shardis. Samuti on kirjad ise osadeks jaotatud, kus manused on serveri pool kirjadest eraldatud ning võivad asuda hoopis mujal. Alles kliendi päringu peale otsitakse need erinevad jupid klastris pealt kokku ja esitatakse kasutajale tavalise e-kirjana. Selle kohta võiks öelda, et tegu on üsna tüüpilise pilve-mudelil töötava lahendusega.

Veebimeili puhul võib IMAP protokolliga seonduva osa täiesti vahele jätta ning saame meiliserverist küsida andmeid üle standardse REST API. Kusjuures kogu töö e-posti vormindusega jääb serveri kanda, nii et veebimeil ei pea midagi teadma MIME-kodeeringutest ega sellest, et kuidas manuseid kirjadest kätte saada. Sama API annab koheselt teada ka kõikidest kontol toimunud muutustest, sealhulgas siis kaustade ümbernimetamisest ning kirjade lisandumistest/kustutamisest.

Keskne autentimissüsteem võimaldab granulaarset haldust, kus kasutajal võib olla mitu erinevat parooli ning igal paroolil saavad olla erinevad õigused mingite toimingute teostamiseks. Samuti võimaldab see paremini paroolide kasutamist logida ning seda logi kasutajale vajadusel ka näidata.

Küberrünnak Zone.ee e-posti süsteemide pihta? Ei, täiesti tavapärane pilt 60 sekundi jooksul mõõdetud automaatsete skännerite katsetest kasutajate postkaste üle võtta. Niiviisi need Minunimi123 tüüpi paroolidega kaitstud kontod langevadki

Iga tegevuse kohta on võimalik saata struktureeritud infot kas Greylogi või muusse sarnasesse logiserverisse, väljuvate kirjade queue seis on loetav Prometheuse formaadis, nii et sisepilt e-posti serveri töösse on tunduvalt parem ning anomaaliad kergemini tuvastatavad.

Lõpetuseks

Kõiki lisandunud võimalusi ei hakkagi üles lugema, muidu ei jää uuteks blogipostitusteks enam materjali. Kokkuvõtvalt võib küll tõdeda, et sellise e-posti süsteemi arendus ei ole olnud lihtne, see on võtnud kaua aega, aga loodetavasti on tulemus seda väärt. Siiani ei ole keskmise suurusega e-posti teenuse pakkujatele sobivat platvormi leidunud, eelkõige mõeldes siis muutunud kasutajaharjumuste ning postkastide suuruse peale, nüüdsest võibolla siis on.

LS17 – üks jube tudengiprojekt “väikse” tagauksega

Siin postituses kirjeldan eelkõige ainult omaenda tegevust, kuid suures plaanis oli see vaid tilk meres, iga teine võistkonna liige tegi oma süsteemide kaitsmisel vähemalt sama palju või rohkem.

Veebirakenduse kaitsmisest pole suurt kasu, kui näiteks võrk ei tööta või serverid ei käivitu. Pealegi oli see vaid üks osa tehnilisest süsteemist, aga lisaks tehnilisele käis kibe töö ka muus osas, mis käis juba üle meie peade. Juriidiline osa, meedia, koordineerimine jne.

See postitus on teine osa järjejutust, mis võtab kokku Andrise ja Peetri poolt Locked Shields 2017 küberõppusel kogetu.
Loe ka:

Ettevalmistus

Esialgu teadsime nendest rakendustest ainult nii palju, kui üldskeemi pealt oli näha. Osaliselt võis aimata, et millega tegu, osaliselt mitte nii väga, nii et vähemalt mina midagi väga ette planeerida ei osanud.

Tutvumispäevadel, nädal enne õppuse algust, pääsesime ligi juba kõikidele süsteemidele, va. üks puuduv veebirakendus, mille kohta oli teada ainult selle üldkirjeldus. Kuna see veebirakendus oli üks minu ülesannetest, siis jäi sellevõrra rohkem aega vaadata üle muid oma vastutusvaldkonna asju. Koos kolleeg Peetriga majandasime erinevaid veebirakendusi ning saime selleks vajalikku tuletoetust Linuxi adminnidelt.

Esialgu tundus kõik üsna keeruline, tegelesin e-posti serveriga, kuhu olid paigaldatud ka veebipõhised mailikliendid ning rakenduste paljususe tõttu paistis auke igalt poolt. Minu suurimaks lemmikuks oli näiliselt juhuslike “vigade” (muutuja nime muutev trükiviga siin, konfiguratsiooniviga seal jne.) tõttu tekkinud olukord, kus veebi kaudu ligipääsetavasse faili logiti kõike, sh. kõikide kasutajate paroole, mida normaaloludes kuidagi juhtuda ei tohiks.

Teise päeva lõpuks tundus asi juba täiesti kontrolli all olevat. Toimetasin serveris rahulikult ringi, otsisin vigu, parandasin neid ning tegin koopiaid (vahetult enne võistlust tehti kõikidele süsteemidele initsialiseerimine ja parandused oleksid kaotsi läinud), kui monitooringu poolelt tuli äkki teade, et sellessamas masinas istub mingi beacon. Läksin ja vaatasin, tõepoolest olid monitooringus näha kummalised payloadid C&C serverisse.

Vasak silm hakkas tõmblema.

Päev 0

Esimene õppusepäev oli samuti harjutuspäev. Nüüd olid kõik süsteemid lõplikul kujul üleval ja saime nendega kuni õhtuni toimetada, mil need seekord juba viimast korda initsialiseeriti. See muidugi tähendas, et ka minule määratud üllatusrakendus oli masinas olemas.

Esialgu paistis see olevat tavaline PHP+MySQL veebirakendus, kuid ühes kaustas asusid veel mingid shelli skriptid ja teises asus midagi, mis paistis nagu Pythoni deemon. Juba põgusa pealevaatamise alusel võis hinnata, et rakendus oli kõikvõimalikke auke täis. Mis polnud ka ime, arvestades, et rakendus oligi kirjutatud spetsiaalselt selle võistluse jaoks.

Esimese asjana võtsin ette PHP koodis SQL-injectionid. Neid oli muidugi igat sorti, osaliselt olid koodis SQL argumendid töödeldud addslashes funktsiooniga SQL päringu stringi sees, osaliselt pandi $_REQUEST muutujast tulevad väärtused lausesse otse (injection!), osaliselt kasutati custom töötlemisfunktsioone, mis kasutasid muidu küll addslashes’it, aga tagastasid tulemusest vaid fikseeritud pikkusega osa (peidetud injection!), mis omakorda oleks võimaldanud stringe lõpetada tagurpidi kaldkriipsuga.

Joonis 1.  Kui $user_id oleks string, tuleks sealt eemaldada kõik, mis võimaldab kavandatud SQL lausest välja hiilida, täisarvu puhul oleks õigem teha kohe intval($user_id). addslashes() on turvalisema mysqli_real_escape_string() asemel kasutusel kuna maandas enamuse riskist, oli lihtsam lisada ja võimaldas seetõttu suurema hulga koodi üle käia. Päris-elus tuleks võtta kasutusele PDO ja prepared statement. Selles kiiruga tehtud paranduses on muideks üks kala sisse jäänud  😉

Parandasin seejärel kõikvõimalikke muid koodi ja konfiguratsioonivigu. Küll oli vales kaustas lubatud valet tüüpi faile käivitada kui PHP’d (kirjutasin uued .htaccess reeglid kõikide kaustade jaoks), küll olid pildifailid PHP koodi täis (kirjutasin hex editoriga nendesse uue koodi), kõikvõimalikud tmp ja puhvri kaustad asusid web root kaustas ning olid muidugi ka veebist loetavad. Siis veel mitmel eri viisil koodi käimatõmbamine valest failist (ehk include $_REQUEST[‘page’];), veebist loetavad konfiguratsioonifailid (MySQL konto andmed!), kasutaja sessiooni andmete muutmine cookie kaudu jne.

Sinna juurde veel vead Apache enda konfiguratsioonis (täiendav rivi faililaiendeid, mida käivitati PHP koodina, lahtine cgi-bin, server-status jmt), eelinstalleeritud cron, kummalised PHP seaded (aegunud sessioonide GC oli välja lülitatud) jmt. Päeva lõpuks tundsin juba end päris hästi, paistis, et kõik on kontrolli all.

Joonis 2. Kui oled lasknud oma serveri üle võtta, tasub kahelda kõiges. Ükshaaval selliste pisimuudatuste otsimine on võimatu – turvalisem on kõik-kõik-kõik asendada originaalide või oma koostatuga. Ning jälgida, et süsteem ikka tõesti võtab konfifaile sealt, kust sina arvad.
Päev 1.

Algas esimene tegelik õppusepäev, kõik süsteemid olid taastatud jälle algseisu ning meile anti pool tundi peale mängude käivitamist, et oma parandused süsteemis ära teha. Kuna automaatsete parandustega tekkis mingi jama, lükkasin oma veebirakenduse muudatused üles kiirelt käsitsi. Kontrollisin, kõik töötas, läksin võtsin kohvi.

36 minutit ja 6 sekundit peale mängude algust lendas peale esimene rünnak, mis kohe ka õnnestus. Rakenduse veebilehelt vahtis vastu “Peace Brigade is here” sõnum, maatriksi rohelised kukkuvad sümbolid taustal. Suu kukkus lahti, mul oli kõik ju kontrolli all?

Tuli välja, et muidugi ei olnud asjad kontrolli all. Olin ära unustanud templiidifailid põhjalikult üle käia. Kuigi osa html koodi escape’imist tegin ära juba PHP koodi poolel, siis põhitöö käis templiitides. Midagi olin nagu teinud, aga ilmselt mitte piisavalt. Ahvikiirusel käisin siis kõik templiidifailid läbi ja toppisin escape filtreid täis ning kirjutasin baasis muudetud kirjed üle, et defacementi eemaldada.

Päris korda kohe kõike ei saanud, veidi läks veel neidsamu defacemente läbi ning lisaks õnnestus mul osad templiidid nii ära rikkuda, et osa funktsionaalsusest enam ei töötanud, kuna templiiti ei saanud laadida. Parandasin süntaksivead ükshaaval ära ning tundus, et kõik on jälle kontrolli all.

Kell 13:00 hakkas teine faas ning sellega koos hakkasid laekuma SQL-injectioni katsed. Nendega paistis siiski kõik korras ning kasutajad nimega 1=1 sisse logida ei saanud.

Joonis 3. Syslog ei pruugi olla küll kõige mõistlikum koht… aga hädaga ajab kiirema asja ära. Allpool loginäide lihtsamat sorti SQLi’st:
Apr 26 10:09:45 scheduler[9524]: url=/admin/login.php message=Login failed for "or/**/1=1# session=[]
Apr 26 10:09:45 scheduler[9524]: url=/admin/login.php error=Wrong username or bad password session=[]

Veel 10 minutit hiljem hakkasid tuvastamata põhjustel toimuma anomaaliad. Kõigepealt tekkisid vead rakenduse näitamisel, ilmnes et kettaruum on otsa saanud. Kettaruumi oli ära kulutanud /tmp kaustas asuv hiigelsuur fail. Vaatasin seda less’iga ja nägin vaid suurt kogust nullbaite.

Siis juba ilmnesid probleemid baasiga. Või õigemini selle puudumisega, keegi oli nimelt kell 13:41 andmebaasi ära kustutanud. Lisaks ilmselgele probleemile – veebikasutajal oli õigus kutsuda välja DROP DATABASE, mis sai käigu pealt ka parandatud, oli ikkagi küsimus, et kuidas?

Taastasime baasi backupist.

Mõne aja pärast hakkas veebirakendus näitama out of memory veateateid. Tuli välja, et baas oli jälle läinud. Seekord küll mitte täielikult (polnud enam kustutamise õiguseid), vaid tabelid olid tühjaks tehtud, va. üks mis oli täis gigabaitide jagu x tähti (selleks andis võimaluse tõsiasi, et viimne kui üks tekstiväli andmebaasis oli TEXT tüüpi). PHP rakendus proovis kõiki neid ridu ühte massiivi sisse lugeda ja sellest ka veateade.

Taastasime baasi backupist.

Nüüd läks asi päris hulluks. Otsustasin teada saada, et kuidas see kustutamine juhtub ning hakkasin kõikvõimalikku logimist peale keerama. Viga parandada ei proovinud, kuna ei teadnud, et kust otsida. Selle asemel lootsin saada uutest rünnakutest piisavalt palju infot, et auk selle kasutamise järgi üles leida.

Joonis 6. Tavapäraselt jookseb veebiserveri logisse päring – ja GET-päringu puhul ka parameetrid. POST-päringu body’s olevad parameetrid, aga ka küpsised jms, jäävad peitu. Nende logimiseks saab kasutada nt Mod Security’t, aga kui on kiire, tuleb leiutada. Igas rakenduses on mingi konfifail, mis laetakse igal päringul – see on ideaalne koht oma logimislahendusele… ja pilt on lõigatud ära realt, kust algas kaitsemeede.

Keegi kustutas baasi ära, meie lasime selle kohe tagasi ja nii mitmeid kordi. Lõpuks hakkas tekkima failidesse pahaseid sõnumeid, et tegeleme cheatimisega. Mõtlesin, et võiks kuidagi vastata, aga ei viitsinud. Sest lõpuks oli eesmärk käes, sain piisavalt infot, et mis toimub. Paraku kaasnes sellega ka 250 miinuspunkti, sest pidev taastamine kohtunikele ei meeldinud.

See keegi kasutas rakendust ennast webshellina. Saatis sinna kodeeritud pakette, mis tõmmati mingil viisil PHP koodina käima. Päris hästi ei saanud aru, et kuidas see mehhanism töötab, aga paha payload oli kätte saadud ning panin sisenemisaugu kinni, nii et seda rohkem käivitada ei saaks.

Joonis 4. Veebirakendus endiselt töötab

Ma ei hakka siinkohal avaldama, et kuidas webshell täpselt töötas, kuna hammustasin selle lahti alles peale võistlust. Võistluse ajal sain vaid aru, et payload on base64 kujul mingisugune läbu, olid omad kahtlused selle sisu formaadi kohta, aga päris kindel ei olnud. See jõudis rakenduseni ja seal siis mingi asi võttis payloadi lahti ja pani käima.

“Aga miks te lihtsalt päringu parameetreid ei filtreerinud?” Kui pahalane on sinu koodis sees, siis võib ta mõelda välja lõputult lahendusi, kuidas see kood saab oma peremehega suhelda. Oleme kavalad ja teeme intval($some_id) – aga võibolla tilguvad käsud sisse selle sama ID järjestikuste väärtustena? Ainus lahendus on tagauks üles leida, ideaalmaailmas tehes totaalse code-review… piiratud ressursi puhul tuleb logida ja leppida sellega, et mõned ründed läbi pääsevad.

Vaikselt hakkas ka paranoia tekkima. Iga nurga tagant paistsid punaste kõrvad:

Mul on siin mingid kummalised OPTIONS päringud. JA NEED TULEVAD LOCALHOSTIST!
Need on monitooringupäringud
Aa okei, hea küll

Päeva lõpus prooviti veel üht auku, mis oli pool-lahti. St. et saadi käima tõmmata PHP funktsioone, kuid selleks funktsiooniks, mida käima prooviti saada, oli system (kusjuures jälle läbi templiidisüsteemi, aga teise augu kaudu), mis oli Linuxi adminni poolt just 5 minutit tagasi ära keelatud. Seega ei läinud see funktsioon käima ning suutsin vastava augu ka kiirelt kinni panna, et teisi funktsioone proovida ei saaks.

Kui kell viis mängu võrk kinni pandi oli kergendus suur, aga tunne oli pigem positiivne, kõik paistis olevat kontrolli all. Õhtul võtsin koodi kodus ette ja käisin templiidid veel korralikult üle, et kõik oleks korralikult escape’itud.

Päev 2.

Esimese asjana uuendasin koodifailid ära, et oleks kõik kindel. Paraku hakkasid üsna pea samad jamad peale nagu eelminegi päev. Andmebaasi ilmus kummaline rida uue kasutajaga, kellel olid märgitud rakenduse adminni õigused. Toimusid mingid anomaaliad. Tundus, et midagi oli selle templiidisüsteemiga endiselt väga valesti. Käisin järgmiseks üle koodi poole, kus templiiti välja kutsuti ning eemaldasin kõik templiidile edastatavad muutujad, mida polnud hädasti vaja. See paistis aitavat, anomaaliad kadusid. Tagantärgi selgus, et olin õhtuste parandustega vana augu uuesti lahti teinud.

Üsna pea tekkisid katsed kasutaja õiguste eskaleerimiseks, kus küpsise abil üritati sättida endale selliseid sessiooni andmeid, mida tegelikult ei olnud. Seda võimaldav viga oli juba ammu parandatud ja seega üritus läbi ei läinud.

Küll aga olid endiselt alles tegelikult juba eelmisel päeval välja tulnud probleemid õigustega – kasutajad said teha rohkem, kui neil oli lubatud. Meetodite autoriseerimiskontrollid olid nõrgad (adminnile ette nähtud tegevusi sai teha ka tavakasutaja) või puudusid üldse (igaüks kes oskas õige päringu koostada sai tegevust läbi viia). Ning seda muidugi kasutati ka ära. Õnneks sain nende aukude puhul kiirelt jaole ja muutsin käsitsi muudetud andmed tagasi, seekord me andmebaasi taastamist ei teinud.

Mingi hetk läks juba igavaks, kõik teadaolevad augud olid kinni, mis andis võimaluse minna üle ofensiivsemale taktikale. Kuna mul oli logimine päris hästi paigas, oli reaalajas ülevaade, et mis parasjagu rakenduses toimub ja kes seal toimetab, tuvastasin kahtlase liikluse kohe selle tekkimisel.

Kohe kui ründaja midagi teha üritas, tegin oma liigutused vastu. Ründaja registreeris uue konto. Mina kustutasin selle konto baasist ära ja tegin PHP sessiooni kausta tühjaks. Ründaja tegi uue konto. Mina kustutasin ära. Ja nii väga palju kordi. Vahepeal lasin ka veidi toimetada, vaatasin, et millega tegeleb, aga esimese POST päringu peale lendas konto jälle minema. See ei olnud mingil viisil skriptitud, tegin kõike käsitsi.

Ühel hetkel aga hakkas üks “päris” kasutaja kurtma, et tal ei õnnestu uude kontosse sisse logida, mille tagajärjel pidin oma hoogu maha tõmbama. Hiljem tuli välja, et kuna punastel konto loomine minu vastutegevuse tõttu (millest nad ei teadnud) ei õnnestunud, palusid nad seda proovida ühel “päris” kasutajal ning kuna see sattus ajaliselt ja välimuselt kokku punaste tegevusega, arvasin, et ka see “päris” kasutaja on punane ja kustutasin ka tema kontod ära. Üldine arvamus punaste poolel oli, et tegeleme cheatimisega, taastame cronist baasi iga hetke tagant ning peaksime saama miinuspunkte. See siiski ei olnud nii ja õnneks miinuspunkte ka ei saanud.

Punaste kahjuks ja minu õnneks oli tava-trafficu genereerimine korraldajate poolt üsna kehval järjel või puudus üldse, mis andis kogu punaste tegevuse mulle selleks hetkeks nagu peo peal ette. Nemad arvasid, et tegutsevad suitsukatte all, mina aga vaatasin seda tegevust sisuliselt läbi suurendusklaasi.

Joonis 5. Tüüpiline monitooringuvaade veebirakenduse staatusest võistluse ajal

Päris lõpus keskendusid põhirünnakud juba muude süsteemide vastu, veebi poolel midagi põrutavat ei toimunud. Üritati vahelduva eduga mingeid lihtsamaid SQL-injectioneid stiilis id=sleep(1337) ning ka skriptifailide üleslaadimist, aga kui midagi osaliselt kehvade õiguste kontrolli tõttu läkski läbi, sain sellise augu momentaalselt elimineeritud, nii et ründaja ei saanud ilmselt arugi, kui tal miski õnnestus.

Tulemus

Veebiosa lõpptulemus oli väga hea, kuna punased suutsid püstitatud eesmärkidest meie vastu saavutada vaid üksikud. Peetri asjadest ei saadud vist üldse läbi ja minul olid need mõned custom rakenduse augud, millest läbi saadi. Väga suur osa selles tulemuses oli ka Linuxi adminnidel, tänu kellele sai leitud mitmeid konfiguratsiooniauke ning kes aitasid rakendusi kogu selle aja püsti hoida. Oli väga hea tiimitöö ning tulemus oli ka näha, sest meie võistkond sai kokkuvõttes teise koha, kaotades üldvõitjale väga napilt.

Ühtepidi oli muidugi kahju, et võistlus läbi sai, aga nii intensiivset koormust taluda ei oleks enam väga kaua suutnud. Kokkuvõttes võib öelda, et sellised õppused on väga vajalikud, kuna reaalse ründesituatsioonita võib ju teoretiseerida, et kuidas end kaitsta, aga kui käsi tegelikult mustaks ei tee, siis see jääbki ainult teooriaks. Õppisin nädalaga rohkem, kui muidu aastaga ja see vist oligi kogu asja eesmärk. Mission accomplished.

Järjejutu kõik osad:

Andmebaasi indeksi kasutamine ja selle mõju MySQL ning MariaDB andmebaasidele

Räägime andmestruktuurist nimega andmebaasi indeks, sellest millist mõju avaldab selle kasutamine MySQL või MariaDB andmebaasi kasutava rakenduse kiirusele ning näitame, kuidas indekseid luua.

Tihti pöördutakse meie poole murega, et koduleht on aja jooksul aeglaseks muutunud. Kuigi selliseid sümptomeid võivad põhjustada mitmed erinevad asjad, näiteks miljoni spämmikommentaari lisamine spämmerite poolt – kui kodulehel on kommentaaride kuvamine välja lülitatud, siis ei ole neid kommentaare küll näha, kuid koormust tekitavad ikka. Reeglina on siiski põhipõhjuseks ning ka esimeseks asjaks, mida üldse vaadata, andmebaasi indeksid. Kodulehe sisu on aja jooksul kasvanud, andmebaasi mootoril on tulemusi aina raskem üles leida ja see avaldubki aeglase lehelaadimisena. Appi tuleb andmebaasi indeks.

Loe edasi “Andmebaasi indeksi kasutamine ja selle mõju MySQL ning MariaDB andmebaasidele”

MongoDB andmebaas Zone Virtuaalserveris

Virtuaalserverite võimekus muudkui kasvab. Nüüd lisandus võimalus kasutada MongoDB NoSQL andmebaasi. Selgitame millega tegu.

MongoDB logo

Virtuaalserverite kasutajatele on nüüd saadaval MongoDB, maailma üks tuntumaid NoSQL andmebaasimootoreid. Ühtlasi toob MongoDB ja Node.js ühine toetamine meie klientideni niinimetatud MEAN arenduskeskkonna toe, mis koosneb komponentidest MongoDB, Express, Angular ja Node.js.

Loe edasi “MongoDB andmebaas Zone Virtuaalserveris”

Võitlus spämmiga ja seda pärssiv “skriptide internet”

Tänane postitus räägib sellest kuidas “skriptide internet”, millel püsib mõõtmatu kogus äriloogikat ja e-majandust, takistab rämpspostiga võitlemist.

Rämpsposti teemal klienditoe poole pöördujatel on enamasti üks kahest küsimusest:

a) “kuidas saaksite teha nii, et mulle saadetud kirju efektiivsemalt rämpspostina tähistataks/kustutataks”;
b) “kuidas saaksite teha nii, et minu saadetud kirju rämpspostina ei tähistataks/kustutataks”?

Juhtub ka nii, et lühikese ajavahemiku jooksul pöördub nende küsimustega meie poole üks ja sama inimene.

Hulk probleeme, mis raskendavad nende kahe küsimuse vahel taskaalu leidmist pärineb allikast mida kutsume “skriptide internetiks”.

Aga enne selleni jõudmist, väike minikursus teemal …

“… kuidas kirju spämmiks märgitakse?”

Kiri liigub saatjalt adressaadini läbi mitme erineva serveri, tekitades sellega sammude ahela, mille iga lüli võib kirja ühel või teisel viisil “spämmisuse” suhtes kontrollida.

Saatja MUA ehk meiliklient võtab ühendust oma MSA-serveriga (Mail Submission Agent), autendib end ja annab kirja üle. MSA omakorda võtab ühendust väljuva MTA-serveriga (Mail Transfer Agent), mis on kirjade transportimise server. MTA salvestab kirja järjekorda ning üritab seda esimesel võimalusel edastada vastuvõtja MX-serverile (Mail Exchange), mis omakorda annab selle üle MDA-serverile (Mail Delivery Agent) ja lõpuks jõuab kiri saaja postkasti, kust saaja saab oma MUA-meilikliendi abil kirja lugeda.

Seda, kui “spämmine” kiri on, kontrollitakse enamasti järgmiste etappidena:

1. Sõnumitooja kontroll

Esimene tase on kontrollida mitte sõnumit, vaid sõnumitoojat. Näiteks kui kirja saatev server on mitmes mustas nimekirjas, võib kiri sattuda spämmiks juba ilma, et keegi selle sisu üldse vaataks. Kusjuures saatev server või õigemini serveri poolt kasutatud IP aadress ei pruugi ise olla kunagi midagi halba teinud, aga ikka peetakse seda kahtlaseks.

Tavaliselt on siis tegu kas mingi suurema IP vahemiku või veel hullemal juhul terve teenusepakkuja (ASN-numbri alusel) sattumine mõnda musta nimekirja. Mustad nimekirjad ei ole samas absoluutsed, neid võib pidada igaüks ning nimekirja haldaja võib koostada neid nagu ise heaks arvab. Oluline on, et kui paljud teised teenusepakkujad mõnd konkreetset listi usaldusväärseks peavad ning seda oma spämmikontrolli protsessis kasutavad. Sellist kontrolli tehakse samas pigem sisenevate kirjade puhul, kuna väljuvate jaoks peab kasutaja end reeglina autentima ja sellisel juhul ei ole saatja IP nii oluline.

Kui ühenduse avamine on lubatud, siis edasi vaadatakse sõnumitooja käitumist, et kas see ikka kasutab korrektset SMTP-protokolli. SMTP-klient peab ootama korrektselt oma rääkimiskorda, isegi kui server vastustega venitab. Klient peab kasutama enda tutvustamisel õiget domeeninime, ei tohi kasutada tundmatuid SMTP käsklusi, ei tohi saata kirja liiga paljudele tundmatutedele aadressidele jne. Mõned süsteemid kontrollivad ka TCP ühenduse sõrmejälge, et tuvastada kas saatjaks on meiliserver, või hoopis töölauaarvuti. Iga vea või mittevastavuse eest annab vastuvõttev server kas spämmipunkte või suuremate vigade korral katkestab üldse ühenduse ja keeldub kirja vastu võtmast.

Kui protokolli kontroll on läbitud, vaatab vastuvõtja juba SPF-kirjet ja selle vastavust. Juhul kui MAIL FROM käsus kasutatud saatja domeeninimel on seatud nimeserveri SPF-kirje, saab selle järgi kontrollida, kas saatja IP aadressilt ikka tohib sellist domeeninime kasutades kirju saata või mitte. Kui kliendi IP aadress on 217.146.66.121 ning e-posti aadressiks andris@zone.ee, siis kõik sobib, kuna zone.ee SPF-kirje lubeb muu hulgas ka 217.146.66.121 aadressi kasutamist. Kuna SPF on mitme vastavustasemega, siis siin jälle sõltub erinevatest asjaoludest, et kas server laseb kirja niisama läbi, keeldub seda üldse vastu võtmast või lisab mõned spämmipunktid.

2. Kirja vormistuse kontroll

Kirja enda puhul on kontrollitavaid parameetreid veelgi rohkem. Üheks olulisemaks asjaks on kirja vormistus, kas see kiri ikka näeb RFC822 formaadis kirja moodi välja või mitte. Kirjal peab olema From aadress saatja andmetega, Message-ID unikaalne identifikaator, kuupäeva Date väli, protokollist tulenevalt peavad reavahetused kasutama nn. Windowsi stiili ehk baite 0x0D+0x0A (carriage return + newline) jne. Iga puuduv või valesti vormistatud osa annab spämmipunkte. Tüüpiliseks vale vormingu näiteks on vigane kuupäevaväli (peab olema “Wed, 14 Dec 2016 10:58:26 +0200” aga on hoopis “2016-12-14 10:58:26”) või siis Message-ID puhul väiksem-kui ning suurem-kui märkide puudumine või kui väärtus ei kasuta e-kirja aadressi süntaksit (peab olema “<unikaalne-id@domeen>”, aga on “unikaalne-id”).

3. Krüptograafiliste allkirjade kontroll

Kui kirja vormistus vastab enamvähem nõuetele, siis vaadatakse ka selle sisu. Kas From real oleva aadressi (mitte segi ajada SMTP-ümbrikus kasutatud MAIL FROM aadressiga, mis moondub ühel hektel hoopis Return-Path väärtuseks) domeenile on seatud DMARC nimeserveri kirje või mitte? Kui on, siis kontrollitakse uuesti SPF-kirje vastavust, aga seekord juba From välja alusel. Lisaks vaadatakse kas kirjal on sobiva domeeni DKIM-alkiri.

Selle koha peal võib server kirja tagasi lükata ka siis, kui kirjal spämmipunkte üldse ei ole. Kui DMARC-kirje ütleb, et vigane kiri tuleb tagasi lükata, siis server seda suure tõenäosusega ka teeb. Vigaseks teeb kirja vale SPF (võib juhtuda näiteks, kui kiri saabub hoopis mõne meililisti kaudu) ja vale DKIM (reeglina juhtub siis, kui kirjal pole üldse vajalikku DKIM-allkirja, kuna kiri liikus selliseid kanaleid pidi, kus allkirjastamist ei toimu, näiteks läbi oma ISP väljuva SMTP-serveri kirju saates).

Edasi vaadatakse läbi ka kirja kõik muud DKIM (DomainKeys Identified Mail) krüptograafilised allkirjad. Selliseid allkirju võib olla kirjal palju, erinev allkiri iga seotud serveri kohta. Üks allkiri saatja aadressi domeeni jaoks, teine teenusepakkuja MTA-serveri jaoks, kolmas mingi statistika jaoks jne. Gmail Postmaster Tools veebiliides näitab teenusepakkujatele infot kirjades sisalduvate DKIM-domeenide alusel ja seega on mugav koondada kõikide oma süsteemi läbivate kirjade info kokku, kasutades kõikides väljuvates kirjades ühist DKIM-allkirjadomeeni.

DKIM-allkirja kontrollimiseks vaatab server kirja päises olevat allkirja päisekirjet, otsib sellest allkirja domeeni, läheb küsib domeeni nimeserverist allkirjale vastava avaliku võtme ja kontrollib saadud võtme abil allkirja kehtivust. Kui allkiri on vigane, siis saab kiri jälle spämmipunkte, aga mitte väga palju, kuna katkised allkirjad on suhteliselt tavaline nähtus, selle lõhkumiseks piisab vaid ühest muutunud bitist. Näiteks kui kiri läbib mõnd meililisti, mis lisab kirja lõppu meililisti info või läbib MS Exchange serverit, mis võib vahetada TAB sümbolid tühikute vastu, siis võibki allkiri katki minna, sõltub jälle erinevatest asjaoludest (osad DKIM formaadid taluvad selliseid tühikute-tab’ide vahetusi, osad mitte).

4. Sisuanalüüs

Kirja tekstilise osa analüüs jaotub suures plaanis kaheks. Esimene pool on algoritmilised kontrollid ja teine pool on kirja võrdlemine varasemalt teada oleva spämmiga. Algoritmiliseks kontrolliks võiks olla näiteks phishingu-linkide (ehk need lingid, mis suunavad “ganzapanga” lehele paroole sisestama) otsimine, kus võrreldakse HTML koodi lingis olevat URL’i selle kuvamise aadressiga ning kui need ei klapi, siis antakse spämmipunkte.

<a href="www.aaa.com">www.bbb.com</a>

Kõiki linke kontrollitakse lisaks veel phishingu andmebaaside pihta ning kui link tõesti mõnes phishingu baasis eksisteerib, siis antakse kirjale jälle tublisti spämmipunkte juurde. Siin on küll mõningane valepositiivsete tulemuste tekkimise võimalus, seega sellise lingi olemasolu üksi kirja tagasi lükata ei tohiks.

Teksti võrdlemine teadaoleva spämmi vastu on üks parimaid, aga samas ka segasemaid meetodeid. Levinuimaks klassifitseerimismeetodiks on Bayesi filter, mille puhul võrreldakse kirjas sisalduvaid sõnu teadaolevate spämmikirjades sisalduvate sõnade ja fraaside vastu ning mida erinevam on kirja sisu tavalisest spämmist, seda suurema tõenäosusega polegi tegu spämmiga. Segaseks teeb selle kontrolli asjaolu, et inimesena on raske öelda, miks spämmikontroll mingit kirja spämmiks peab või mitte, sest oma silmaga vaadates võib see paista üsna tavaline kiri. Kuna algoritm ja andmed ei ole ülearu keerukad, siis on võimalik see hea tahtmise korral siiski tuvastada. Hoopis teine asi on juba neuraalvõrkude põhise kontrolliga, mis on väga efektiivne, aga kus ei saa enam keegi ilmselt aru, et miks spämmikontroll mingit kirja spämmiks peab või mitte.

5. Viirusekontroll

Kõige viimasena saadetakse kiri ka veel viirusekontrolli, kus vaadatakse üle kirjas olevad manused ning kohati ka kirja tekstiosa, kui viirusekontroll oskab sellest näiteks phishingut vmt. tuvastada. See on võibolla ka kõige jäigem kontroll üldse, sest kui kirjast leitakse teada olev viirus, siis siin nagu polegi enam midagi mõelda, sellise kirja koht ei ole postkastis. Samas ka viiruste puhul on suhteliselt tavalised erinevad valepositiivsed tulemused, näiteks kui leitakse pakitud ZIP-faili seest kahtlase nimega fail, aga selle sisu täpsemaks uurimiseks pole enam mahti. Sellisel juhul antakse kirjale pigem spämmipunkte, et see satuks spämmikausta, aga tagasi lükkama ka ei hakata.

6. Lõppotsus

Erinevaid reegleid, mida spämmi tuvastusel kontrollida, on sadu ja kõiki siin välja tuua ei jõuakski. Üldpõhimõte on see, et iga reegel annab kas negatiivseid või positiivseid spämmipunkte ning peale kõiki kontrolle lüüakse need punktid kokku ja saadud tulemus ütlebki, et mida kirjaga edasi teha.

Kui kiri pole üldse spämmipunkte saanud, siis võib selle lihtsalt niisama vastu võtta. Kui mingeid punkte on siiski tulnud, aga mitte piisavalt, et kirja spämmiks lugeda, saab kasutada nn. greylistingut, kus saatjale vastatakse ajutise veateatega ja lastakse seega sama kiri mõne aja pärast uuesti saata (spämmerite süsteemid tihti uuesti saatmist teha ei suuda).

Kui punkte on juba rohkem, siis võetakse kiri küll vastu, aga paigutatakse see spämmikausta, jättes sellega lõpliku otsustamise adressadi enda kanda. Kui punkte on juba väga palju, näiteks leiti kirjast viirus, see on kehvasti vormistatud ja tekstisisu sarnaneb spämmiga, siis ei võeta seda kirja võibolla üldse vastu, vaid keeldutatakse teatega, et kiri paistab olevat spämm.

Spämmikontroll väljuvatel ühendustel

Spämmitõrje igal tasandil on muidugi mõistlik tegevus ja seega hakkasime hiljuti rakendama seda lisaks sisenevatele kirjadele osaliselt ka väljuvate kirjade puhul. Teenusepakkujana on meie probleemiks häkitud kontod, kus kasutaja veebileht võetakse pahalaste poolt ära või lähevad meilikonto paroolid jalutama vmt. tegevused ning mille tõttu hakatakse ühtäkki meie võrgust spämmi laiali saatma. Tagajärjeks on meie väljuvate IP aadresside sattumine mustadesse nimekirjadesse ja seega tekivad probleemid ka teiste klientide kirjade edastamisel, mis liiguvad samade IP aadresside kaudu.

Esimene kaitse musta nimekirja sattumise vastu on hajutada saatmisel kirju erinevate IP aadresside vahel, mis võimaldaks võtta musta nimekirja sattunud IP kuni asjaolude selgitamiseni rivist maha (ZoneMTA oskab teha seda automaatselt, nii et ühe IP sattumine musta nimekirja ei tähenda suures plaanis veel suurt midagi). Kuid võibolla olulisemgi oleks üldse vältida spämmi saatmist (kuigi päris täielikult välistada seda muidugi kunagi ei saa), eelkõige kasutades spämmikontrolli.

Paraku ei ole miski liiga lihtne. Maailm on muutunud, e-posti ei kasutata enam ammu ainult personaalseks suhtluseks, üha rohkem ja rohkem on see uudiskirjade, automaatsete teadete, parooli meeldetuletuste jms. maailm. Väljuva liikluse puhul spämmikontrolli teostamine on sisenevast keerukam, kuna eksimisruumi on vähem. Juhul kui kiri paistab kahtlane, siis ei saa seda panna spämmikausta. On vaid üks valik – saata kiri edasi või mitte.

Ja nii jõuamegi müstilise “skriptide internetini”

Meie kasutajad saadavad välja igasugust e-posti. Loomulikult on jätkuvalt olulisimal kohal tavasuhtlus ehk käsitsi kirjutatud kirjad. Viimasel ajal on suur osa kirjadest siiski masinate koostatud, osaliselt on need lausa masin-transaktsioonid, kus ühe masina skripti poolt saadetud kiri tekitab vastuvõtmisel mingi tegevuse teise masina skriptis.

Lisaks võidakse selliste kirjade transpordiks kasutatada neidsamu kontosid, mida kasutatakse ka Webmaili, Outlooki ja muude meiliklientide poolt ehk kus peaks eelkõige liikuma niiöelda “tavakirjad”.

Näiteks kasutab mõni inimene WordPressi (fiktiivset, kuid reaalsele elule lähedast) pluginat NutisaunPro™®, kus veebilehe tarkvara saadab vajalikul hetkel nutisauna kerisele e-kirja, milles sisaldub käsklus keris kuumaks ajada ning nutikeris saadab omakorda vastuskirja, kui soovitud temperatuur on käes. Paraku on need kirjad saadetud PHP mail() käsu abil ning kirja vormistamise skript on kopeeritud HotScripts lehelt PHP kirjade saatmise kategooriast.

Masinate vahelises suhtluses ei tähenda see suurt midagi, kõik toimib, aga kui hakkame sellisele kirjale siseneval või väljuval suunal rakendama spämmivastast kontrolli sarnaselt tavalistele kirjadele, ajab see kõik mõõdikud punaseks järgmistel põhjustel:

  • tõenäoliselt asub nutisaun IoT-seadmena mingis kummalises võrgus, kus pole seatud korrektseid tagurpidi reverse DNS-kirjeid;
  • kirja vormistus on kopipasta tõttu ebakorrektne, puudu on vajalikud päised;
  • teksti kodeering pole korrektselt määratud;
  • kirja sisu on lühike ja segane, tekitades Bayesi kontrollis selle vastu liigset huvi;
  • DKIM allkirja pole lisatud;
  • SPF kirjet ei eksisteeri;
  • DMARC kirjet pole
  • jne.

Spämmifiltreid karmistada ei saa, sest nutisaunade omanikud on kurjad, koju jõudes ootab ees külm saun – keris ei ole vajalikku e-kirja kätte saanud.

Nii tekib olukord, kus selliste “nutisaunade” poolt kasutatavate skriptide kvaliteet saab ühiseks nimetajaks, mille järgi rämsposti on võimalik filtreerida. Loomulikult pääsevad siis liig-kõrge lävendi tõttu efektiivsemalt läbi hästi vormistatud päris spämmikirjad.

Siinkohal kasutatud fiktiivne “nutisauna” näide võib tunduda jabur, aga uskuge meid, reaalsus on jaburam. E-posti on (äri)protsessidesse sisse kirjutatud imelistesse kohtadesse.

Oleks siis veel tegu mõne üksiku juhtumiga, aga kui aus olla, siis oleme avastanud, et meil pole tegelikult õrna aimugi, kui palju ja milleks kõigeks e-posti infrastruktuuri üldse kasutatakse.

Kasutan siinkohal võimalust pöörduda arendajate poole. Kui soovite oma postkastis näha vähem spämmi, palun ärge toitke “skriptide internetti” koodiga, mis kasutab e-posti selleks, milleks ta algselt mõeldud ei ole.