[Tanel]

Eesti ettevõtted kannatavad vähekaitstud meiliserverite ja –süsteemide tõttu igakuiselt tuhandeid eurosid kahju. AKI ja RIA tuletavad ettevõtetele meelde, et nende kasutatavad meiliserverid oleksid häälestatud tagama e-kirjade usaldusväärsust ning kasutaksid vaid krüpteeritud andmeedastust ja sisse logimist.

Asutused nii avalikus kui erasektoris vahetavad omavahel iga päev e-kirjadega erineva konfidentsiaalsusega teavet. Olgu selleks e-poe tellimused, arved, teenuste tarbimisinfo, ametiasutuse tagasiside pöördumistele või perearsti suhtlus patsiendiga. „Kõik need kirjad sisaldavad vähemal või suuremal määral inimeste eraelulist teavet. Kui see info jõuab valedesse kätesse, siis see annab aimu, milliseid teenuseid ja mis mahus inimene kasutab ning seda saab ära kasutada raha välja petmiseks,“ lausus RIA intsidentide lahendamise osakonna (CERT-EE) juht Tõnu Tammer.

Kui e-posti aadress on lihtsalt võltsitav või internetis liikuv info satub krüpteerimata e-posti võrguliiklust pealt kuulava pahalase kasutusse, võib inimene või ettevõte sattuda küberkuritegude ja kelmuste ohvriks. „Saame igapäevaselt teateid juhtumitest, kus inimese on sattunud pettuse või kelmuse ohvriks ning väga paljudel juhtudel on see võimalik just kehvasti kaitstud e-posti süsteemi tõttu. Ainuüksi märtsi teises pooles said paar ettevõtet enam kui 80 000 eurot kahju,“ ütles Tammer. Ta lisas, et ettevõtted peaksid kindlasti oma serverid või teenused üle kontrollima, et oleks tagatud turvaline e-kirjavahetus ja vajadusel tegema muudatused.

Tihti antakse CERT-EE-le teada väljapressimistest. „Inimeselt nõutakse raha, et kirja saatja ei avaldaks tema privaatseid andmeid. Inimesele luuakse pettekujutelm, et pahalasel on tema kohta delikaatset infot. Reaalsuses segatakse aga kokku tõene info, näiteks varasemalt lekkinud parool, ja valeinfo. Nii jääbki inimesele mulje, et tema kohta on päriselt sensitiivset infot, kuigi see pea kunagi nii ei ole,“ rääkis Tammer.

Veelgi tõsisem privaatsusriive kaasneb aga siis, kui e-posti teenusesse sisse logimisel võimaldatakse kasutajatunnuste ja paroolide krüpteerimata edastamist. Näiteks halvasti seadistatud wifi võrgus saab pahalane lihtsate vahenditega teada sama võrku kasutavate inimeste kasutajanimed ja salasõnad, kui e-teenuse pakkuja ei kasuta krüpteerimist. Nii võib ründaja oma kontrolli alla saada inimese kogu e-postkasti või mõne muu suhtluse või sotsiaalmeediakonto ja tõsiselt halvata inimese igapäevaelu. Tammeri sõnul saavad nõrgalt kaitstud meiliserveritest ja –süsteemidest alguse ka petuskeemid, kus ettevõtted saavad libaarveid. „Näiteks saab ettevõtte raamatupidaja arve või maksepalve justkui õigetelt lepingupartneritelt, kuid reaalsus mängib partnerit e-kirjadele silma peal hoidnud kurikael,“ märkis ta.

Krüpteerimine on üks esmaseid vaikimisi andmekaitse põhimõtteid, millega organisatsioonid saavad tagada isikuandmete infotehnilise turvalisuse. Sageli ei too krüpteerimine lisakulutusi, piisab, kui pädev IT-spetsialist vaatab üle olemasolev tehnoloogia turvasätted. Niisamuti on tehniliste vahenditega lihtsasti võimalik vältida sinu enda või sinu ettevõtte aadressilt tulevate võltsitud e-kirjade kohale jõudmist.

Mida teha turvalisuse tõstmiseks?

E-posti serverite vahelise andmevahetuse paremaks kaitsmiseks tuleb sisse lülitada STARTTLS tugi ning kindlasti eelistada krüpteeritud andmevahetust: seda nii e-kirjade saatmisel kui ka vastuvõtmisel. Samuti tuleks e-postiserveritel sisse lülitada SPF ja DMARC kontrollid ning samamoodi seadistada ka oma internetiaadress ehk domeen. Selle abil on võimalik vältida näiliselt iseenda või ettevõtte aadressilt tulevate võltsitud e-kirjade kohale jõudmist sulle või sinu äripartneritele.

Oma kodulehe ja e-posti serveri seadistuste turvalisuse kontrollimiseks on olemas mitmed internetipõhised lahendused. Nende lühitutvustuse leiab RIA blogist (https://blog.ria.ee/oma-kodulehe-voi-e-posti-turvalisust-saab-testida-igauks/).

Allikas: https://www.aki.ee/et/uudised/uudiste-arhiiv/turvaline-e-posti-server-aitab-valtida-suurt-rahalist-kahju

[Märt.]

Pahatihti on see lekkinud paroolgi väljamõeldis. Mulle on oma paarkümmend meili saadetud Hoti aadressile, et oh õudu, olen su asjad vangi võtnud ja sind filminud, ning winu parool on xxxxxxx112. Kae nalja, aga pole ligilähedalgi.
Jube lihtsalt võetakse ikka õnge.

[XeStAiSy]

Ma sain ka ühe spämmi kasti oo su parool xxxxxx ja mul on sinu veebikaamerast video mis sa voodis tegid. Irw tahtis saada 900+ euro väärtuses bitcoini ,et video kustutaks. Ilmselt see ammu kustunud juba. Selline asi jätab tõsiselt külmaks.

[netmaster]

Kas AKI ja RIA jätavad meelega rääkimata nendest asjadest mille SPF katki teeb? SPF on nagu endale jalga tulistamine selleks, et keegi sind tagumikust ei näpistaks.

[Renka]

Aga räägi siis ise?

Ma ei tea küll, et SPF midagi katki teeks.

[netmaster]

Kuna peale seda saavad sinu poolt saadetud maili saata ainult sinu mailiserver, ei toimi enam ükski suunamine, listid jms. Kui näiteks mingil firmal on mailiaadress info@firmanimi.ee ja see on edasi suunatud kolmele aadressile, siis sina sinna maili saata ei saa, sest firmanimi.ee mailiserveril pole õigust sinu aadressiga maile edasi saata. jne, jne. Pidasin sel teemal just ühe riigiasutusega väikese sõja maha. Räägi nagu seinale.

PS:
Pealegi pole SPF'iga arvestamine kohustuslik. Niiet põhimõtteliselt teed sa ise enda elu keeruliseks, kuid ei takista tegelikult kedagi sinu nime alt maile saatmast.

[Renka]

netmaster, ole hea konfigureeri oma SPF kirje korrektselt mitte ära väida, et see midagi katki teeb!

Sinna lisad ju usaldusväärsete serverite aadressid.

EDIT: ok sain valesti aru. Väidad hoopis, et see mailinglist saadab kellegi kolmanda osapoole kirju ise edasi sellisel kujul siis kõik on õige - peabki SPF kontrollis põruma.
Kui aga oled kindel, et see kiri tuli just sealt mailingilistist siis tee spämmifiltrisse erand sealt mailinglistist tulnud asjadele. On ju sinu kontrolli all see osa liiklusest.
Puhas konfigureerimise küsimus.

Kolmas osapool ei pea sinu imeliku mailinglisti pärast SPFist loobuma.

[netmaster]

[Renka]

netmaster, sellisel juhul võta oma mailiserveri spämmifiltris SPF kontroll maha ja ongi mure murtud.
Küll aga tunnen kasutajatele siis kaasa keda SPF tõhus kaitse enam ei päästa võimaliku jama eest.

Igal juhul on see sinu mure, et oled oma mailisüsteemi selliselt seadistanud - mitte saatja mure.
Tuleb ajaga kaasas käia ja leida lahendused mis turvalisusega sammu peavad.

[netmaster]

[Renka]

netmaster, ma saan väga hästi aru kuidas SPF töötab. Sina aga ei tundu aru saavat, et sinupoolne konfiguratsioon on probleemne. Mitte saatja kellel on korrektne SPF kirje.

Meenus, et su suunamisele on ka täiesti reaalne ja standardne lahendus olemas SRS näol: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme Mis on loodud just täpselt selle sinu usecase lahendamiseks.

Ma ei saa aru kuidas saab süüdistada RIAt või mõnda muud asutust iseenda tegemata töös? See kui mina saadan korrektse emaili ja mu domeenil on SPF seadistatud ning sinu hallatavas serveris see kiri adressaadini ei jõua siis see ei ole minu tegemata töö. Ikka adressaadi IT osakona poolt on vastu võetud otsused mis ei ole kuigi mõistlikud. Tööriistad ja lahendused sinu kirjeldatud probleemi lahenduseks on olemas juba aastaid (lausa aastakümneid võib vist väita).

[mikk36]

Ettevõtete üldaadressid on reeglina suunatud kuhugi teistele domeenidele, mis asuvad väljaspool antud meiliserverit, kus see üldaadress meile kogub?
On ka enda töökohas üldmeil, meililistid jne kasutusel, pole aga ühtegi muret kasutajatelt seoses kõva spämmifiltriga.
Pigem tuleb sellegipoolest vahest mõni spämm läbi, kuna kontodesse häkitakse sisse (pean silmas ülejäänud maailma) ja saadetakse legitiimsete serverite kaudu neid välja.

[netmaster]

[Renka]

Järjepidevalt üritad iseenda tegemata tööd kellegi teise süüks veeretada ...

[netmaster]

[Renka]

Lahendus on korduvalt siia kirja pandud. Kuidas seda konkreetselt sinu kasutatava tehnoloogia stacki peal teha pead mõistagi ise välja mõtlema.

Huvitaval kombel teistel teenusepakkujatel see ei ole probleemiks ja nad on suutnud asja ära lahendada. Minuteada pea igal pool SRS'iga - nagu ette nähtud.


Meenus Zone poolt 2016 aastal kirja pandud detailne blogipostitus. Ehk on sellest abi: https://blog.zone.ee/2016/10/28/e-kirjade-suunamine-serverite-vahel-voib-olla-ullatavalt-keeruline-seletame-kuidas-seda-viisakalt-teha/

[netmaster]

SRS põhiprobleem on selles, et kõigil levinud MTA'del puudub vastav tugi. Ka seal blogis ta nentis, et ei saanudki olemasoleva süsteemi peal SRS'i käima. Selles kontekstis ma eriti ei usu, et kõik maailma mailiserverid kasutavad oma MTA küljes mingit olematut pluginat või milter filtrit. Põgusa googeldamise peale ei leidnud mina küll midagi muud kui paar aastatetagust projekti githubist ja mõned pythoni scriptid. SPF ei ole probleemiks ilmselt selle pärast, et suunamised sama serveri piires siiski töötavad ja ta ei ole tegelikult nii laialdaselt kasutusel, et see globaalselt märkimisväärset mõju avaldaks. Suured tegijad muidugi saavad lubada omale ise vastava plugina kirjutamist, nagu ka see blogija lõpuks tegi uue MTA koos SRS'iga. Kui sa selle tegemata töö all mõtled, et ma ei ole omale uut MTA'd kirjutanud, siis selles osas on sul küll õigus. Ilmselt ei ole ma ainuke, sest selleteemalisi hädaldamisi leiab netist sadade kaupa.

Mina arvan endiselt, et SPF'i kasutamisel on neli põhiprobleemi:
Esiteks, takistab ta ainult "envelope-from" aadressi võltsimist ja kõiki neid aadresse mida kasutaja tegelikult näeb ("from", "reply-to") saab vähegi kogenum spammer oma suva järgi endiselt muuta.
Teiseks, ei ole SPF'iga arvestamine kohustuslik ja seda ei saa kellelegi peale sundida.
Kolmandaks, nagu juba öeldud, võib ta paljudel juhtudel katki teha suunamised ja muud asjad.
Neljandaks, on SPF oma olemuselt altruistlik, st. sellega vähendab domeeni omanik põhiliselt mitte enda, vaid kellegi teise spammihulka.

Kõike eelnevat arvestades, on tema tegelikku kasutegurit väga keeruline hinnata, kuid minu isiklik arvamus on endiselt, et see mäng ei vääri küünlaid. Spammiga võitlemiseks on palju effektiivsemaid meetodeid. Viimase aja scammimiskampaaniate tulemusel on teda jah soovitama hakatud, põhiliselt selle pärast, et teda on väga lihtne kasutusele võtta ja eks ta mingil määral muidugi aitab. Olen teda ka mõne domeeni peal katsetanud, kuid praktiliselt kohe kasutajate nõudmisel uuesti eemaldanud.

[LKits]

SPF peabki suunamise katki tegemine, sest praegusel kujul suunamine on saatanast!
Miks peaks olema suvalisel domeenil õigus edastada suvalisele aadressile kirju nii, et algsed päised jääksid samaks? Jah, on võimalik seadistada DKIM, aga SPF on täiesti piisav turvalisus.


Mina pooldan 100% SPF-i ning kui on soov teostada suunamisi, siis kasutage "on behalf of" meetodit nii, et algne saatja jääks alles ning "suunaja aadress" jääks samuti kirja sisse. Siis ei kontrollida "vahemehe" SPF-i, vaid algse saatja oma.
See välistab ka tohutul määral taolise nõrkuse ärakasutamist, sest suvalisel serveril ei tohiks olla õigust edasi suunata (ehk tegelikult nii öelda saata) e-kirja suvalise domeeni nimel.

EDIT: Sassi läks.
Siis ei kontrollita algse saatja SPF-i, vaid hoopis vahemehe oma, sest kirja saatjaks on vahemees, mitte algne saatja.

[Betamax]

[Märt.]

[netmaster]

[LKits]

SPF kirje eesmärk ei ole määrata kiri rämpsu, vaid välja selgitada saatja autentsus. Seal on väga suur vahe!
Rämpsuks määratakse kiri vastavalt sisule ja saatja identiteedile (kui on rämpsu saatja).

Kahjuks kontrollitakse SPF kirjet ainult return-path vastavusega. Ning spämmerid teavad seda ja nii mõnelgi korral on return-path autentne saatja, aga FROM päis on võlts ehk miski, mis olla ei tohiks.
On võimalus kasutada DKIM ja DMARC, aga ma ei tea paljud seda teevad.

[BigBabba]

[LKits]

Vajalikkus ja reaalsus erinevad teineteisest.

Üks lahendus on seadistada vastuvõttev e-posti server nii, et kontrollitakse SPF kirjet küll "Return-Path" vastavusega, aga kui FROM ja Return-Path erinevad teineteisest, siis muudetakse FROM päis nii, et seal kuvataks ka Return-Path saatjat või lisatakse "Sender" päis.

Näiteks:
Return-Path: lennart@kits.ee
From: lennart@itlahendused.ee


Muudetakse või lisatakse:
Return-Path: lennart@kits.ee
From: "From lennart@itlahendused.ee On Behalf Of lennart@kits.ee"

või

Return-Path: lennart@kits.ee
From: lennart@itlahendused.ee
Sender: lennart@kits.ee

Ning viimast kuvatakse enamuse e-posti klientide poolt "From lennart@itlahendused.ee On Behalf Of lennart@kits.ee"

EDIT: Ja "otse" suunamine on lausvastik, see peaks ka toimuma nii, et edasisuunaja aadress määratakse "Return-Path" väljaks ning "FROM" võib siis olla algne saatja ning "Sender" päiseks määratakse samuti edasisuunaja.

Näiteks:
Kiri saadetakse aadressilt "lennart@kits.ee" aadressile "lennart@itlahendused.ee"
Kiri suunatakse edasi.

Siis suunamisel mitte mingil juhul ei tohi jääda "Return-Path: lennart@kits.ee", sest kirja edasisaatmisel ei ole ju kirja saatjaks lennart@kits.ee, vaid on hoopis lennart@itlahendused.ee

Ehk siis peaks olema:
Return-Path: lennart@itlahendused.ee
From: lennart@kits.ee
Sender: lennart@itlahendused.ee


Jah, sellist kirja kuvatakse nii, et "lennart@itlahendused" on nähtav ning nii peabki olema taolise suunamise puhul.
Kui ei ole soovi näidata "vahemehe" olemasolu (lennart@itlahendused.ee), siis saatkem kiri otse läbi õige SMTP serveri või lisagem vahemehe e-posti server algse saatja SPF kirjetesse.
Kellegi nimel kirja (edasi)saatmine ilma, et selleks oleks õigus aitab rämpsu levikule ainult kaasa.

[netmaster]

[Renka]

netmaster, sa ei pea oma MTAd kirjutama. Teised inimesed on seda juba teinud. Kasvõi seesama Zone MTA on EUPL litsentsi alusel saadaval: https://github.com/zone-eu/zone-mta

Ma pole EUPL litsentsi tingimustega täpselt kursis - aga eeldan, et võib seda ärilisel otstarbel kasutada.

[LKits]

[BigBabba]

[Dogbert]

SRS (Sender Rewriting Scheme) daemon on edasisaadetavate kirjade päiste muutmiseks, et SPF katki ei läheks.

[netmaster]

[LKits]

[napoleon]

Ma enda MTA-s pole sissetulevate kirjadega üldse SPF kontrolli sisse lülitanud. Liiga palju jura on sellest, samas DNSRBL peab suurema hulga sodi kinni ja on suht lollikindel ehk sellest pole kisa olnud, et mõni õige kiri kohele ei jõua.

[netmaster]

[LKits]

Aga paki sees olev info on ju minu poolt loodud, kirjutatud ning kui kaheldakse, kas see kuller võis toimetada minu paki, siis helistatakse ja küsitakse üle (nii öelda telefoni teel teostatud SPF check).

[BigBabba]

Üldiselt mõttetu vaidlus. Kogu algse teema point on see, et tehke oma e-posti serverid turvaliseks.
Kontrollige, et SPF kirje oleks paigas (kõige rangem -all tase).
DMARC poliitika oleks rejectimise peal.
Kõik su domeeni alt (ka veebiserverist) saadetud kirjad oleks DKIM allkirjaga.
IMAP/POP3/SMTP ei lubaks ilma krüptota ühenduda.
Ja vaadake, et https://www.hardenize.com raport oleks võimalikult roheline.

Spoiler

itlahendused ee spf-is on lubatud KÕIK Google IP-d. SPF tase on ~all ehk softfail. hardenize raport pole kõige ilusam jms

[LKits]

[napoleon]

BigBabba, SPF-s ei saagi ju muud kui ~all panna kui mõni võib kodus oma ISP SMTP kaudu ka midagi välja saata. Ma näiteks kasutan eesti.ee aadressi, sellega pole kuidagi võimalik midagi nii välja saata, et kõik testid rohelised oleks.

[netmaster]

[LKits]

Tõsi - SPF check oleks see siis, kui paki saaja helistaks saatja ettevõttele, mitte töötajale, et kas kuller on volitatud pakki kohale toimetama (ja kõiki järgnevaid pakke samuti, sest SPF ei ole ühekordne).
DKIM oleks see siis, kui kulleril oleks ÜHE paki kohaletoimetamise volitus, allkirjastatud ühel või teisel moel.

EDIT: Ning küll on vahva ajastu, kus meil on võimalus üpris soodsalt saada personaalne e-postikuller. Füüsiliste pakkidega on muidugi mõnevõrra kulukam - eraldi pakikuller tööle võtta?

[netmaster]

jah ok, aitab sellest mõistukõnest.
Kui minu statistika järgi kasutab SPF'i umbes 0,5% mailisaatjatest, siis nädala pärast saab teada, kui popp DKIM tegelikult on.

[LKits]

[netmaster]

[LKits]

Et lausa nii hull, et 0.5% kõikidest kirjadest oli SPF kirje olemas (mitte-tingimata ei läbinud) ning 99.5% ei olnud? Wat? For real?

[netmaster]

[LKits]

Kui võimalik palun pane siia tulemus järgnevalt:
* Mitu e-kirja analüüsisid?
* Mitu e-kirja läbis SPF check-i?
* Sama teema DKIM-ga;

Ma tõepoolest kahtlen, et suur osa kasutab mitte SPF all olevaid servereid kirjade saatmiseks. See tundus normaalsus olevat aastaid, isegi kümneid, tagasi. Tänapäeval on autentimistvajavad SMTP serverid.

[netmaster]

[antiz]

[XeStAiSy]

Kusjuures minule saadetud parool polnud väljamõeldis kuigi see parool oli lekkinud andmebaasist sellist parooli kasutasin umbes 8 aastat tagasi ma vahetan tähtsates kohtades päris tihti. Ma tean milline parool lekkis kuid seda ei kasuta väga ammu. Ilmselt kas oli kuskilt foorumist lekkinud või oli adobe millel hiljaaegu oli sunniline paroolivahetus. See parool oli ajutine ja vähem tähtis. Lekkinud andmebaasist saad emaili kontrollida ja näitab parooli.

[ufo56]