Alley küldje el nekünk az üzenet másolatát. Leveleket kapok e-mailben a pénzátutalással kapcsolatban – mi ez? Mit kell tenni
Jó idő! Ma az SMS biztonsági mentésről fogunk beszélni úgy, hogy az összes üzenetet elküldjük okostelefonjáról e-mailre. Erre mind egyszerűen a levelezés mentése, mind az üzenetek további feldolgozása miatt lehet szükség, például az üzenetekben a szükséges információk (kapcsolatok, nevek, árak stb.) kereséséhez harmadik féltől származó alkalmazások által, amelyek viszont működnek Email. Nézzünk egy lehetőséget az ilyen másoláshoz Android operációs rendszert futtató okostelefon használatával.
Hozzon létre egy postafiókot
Az összes üzenet e-mailben történő elküldéséhez és mentéséhez először regisztrálnia kell egy postafiókot; a yandex.ru levelei tökéletesek erre. Használhatja meglévő postafiókját is, de azt javaslom, hogy regisztráljon egy újat. Először is, idővel nagyszámú SMS-üzenet halmozódik fel benne, ami megzavarhatja a normál levelekkel való munkát, másodszor, ha a postafiókját egy harmadik féltől származó szolgáltatáshoz csatlakoztatja elemzés céljából, ne adja meg a bejelentkezési nevet és a jelszót a benne lévő fő e-mail.
Telepítse az SMS Backup + alkalmazást Android okostelefonjára
Az összes SMS postafiókba küldéséhez telepítenie és konfigurálnia kell a speciális SMS Backup + alkalmazást, amely letölthető a play.goole.com vagy az apk-dl.com oldalról (a Google Playt nem használó okostelefonok alternatívája). ) vagy.
Az alkalmazást Androidon tesztelték: 3.xx, 4.xx, 5.xx, 6.xx; Bejelentették a 2.xx verzió támogatását.
SMS Backup + beállítása
- Indítsa el az alkalmazást;
- Az alkalmazás elindítása után a megnyíló menüben válassza ki a következő elemet: Speciális beállítások;
- Ezután lépjen a Biztonsági mentés beállításaihoz;
- Jelölje be a Backup SMS és az Email tárgy előtagja jelölőnégyzeteket, törölje a jelölést a Backup MMS, Backup Call log (MMS-re és a hívásnaplóra nincs szükségünk, bár biztonsági másolatot is készíthet) jelölőnégyzetből;
- Térjen vissza az előző menübe, és lépjen az IMAP-kiszolgáló beállításai szakaszba;
- Válassza ki a Hitelesítés menüpontot,
állítsa a paraméter értékét Sima szövegre; 
- Válassza ki a Szerver címe menüpontot, írja be az értéket: imap.yandex.ru:993
- Válassza a Biztonság menüpontot, és írja be az értéket: SSL
- Válassza a Login (Your IMAP account) menüpontot, adja meg bejelentkezési adatait, majd válassza a Jelszó (Your IMAP account password) menüpontot, adja meg a yandex.ru mail jelszavát;
- A főmenüben jelölje be az Automatikus biztonsági mentés jelölőnégyzetet;
- Ezután lépjen az Automatikus mentés beállításaiba, válassza ki a Rendszeres ütemezés menüpontot, és állítsa be azt az időintervallumot, amelyen belül az SMS-ek elküldésre kerülnek az általunk megadott postafiókfiókba (például 2 óránként).
Az SMS Backup + alkalmazás lehetővé teszi, hogy ne csak biztonsági másolatot készítsen az E-Mailbe, hanem visszaállítsa az üzeneteket is. A megfelelő helyreállítási beállítások a Speciális beállítások -> Beállítások visszaállítása részben találhatók.
Az üzenetek e-mailben történő elküldése után mindegyik egy SMS nevű mappába kerül.
Az e-mailre küldött SMS-ek elemzése
Miután megkapta az SMS-ek listáját az e-mail címére, speciális szoftverrel elemezheti a bennük lévő adatokat. Például nyomon követheti a bankból érkező SMS-eket a pénztárbizonylatokról és terhelésekről szóló üzenetekkel, amelyek alapján automatikusan vezetheti a pénzügyi nyilvántartást. Hasonló megoldást valósítottam meg a „közös vásárlási oldal” esetében, amikor a JV Szervezők által a Banktól kapott összes SMS-t egy helyre gyűjtik, elemzik és ezek alapján a rendszer adatokat jelenít meg a vezérlőpulton arról, hogy melyik felhasználó helyezte el. a megrendelés teljesítette a fizetést.
Az e-mailek megcímzése a Thunderbird segítségével nem nehéz feladat, de számos módon megtehető, némi eltéréssel a többi levelezőprogramtól. A legnyilvánvalóbb változás, amelyet a Microsoft-termékekről áttelepülő emberek észleltek, az, hogy a Thunderbird csak egy címzettet helyez el minden címmezőbe, így több címzett esetén több címzett is létrehozható. Ez semmilyen módon nem befolyásolja azt, ahogyan a levél megjelenik a címzett számára; ez csupán a Thunderbird tervezési folyamatának korai szakaszában meghozott elrendezési választás eredménye.
Címmezők
Nak nek: Ennek az e-mailnek az elsődleges címzettje(i).
CC:(Carbon Copy) Az e-mail másodlagos címzettje(i). A címzettek a Címzett: és a CC: mezőben láthatják a címzettek e-mail címét
BCC:(Blind Carbon Copy) Az ebben a mezőben lévő címekre kapnak levelet, de a címzettek nem tudják, hogy ki volt a BCC: mezőben, azaz a BCC: mezőben lévők kapják meg az e-mailt, de a Címzett: és a CC: mezőben lévők. nem fogja tudni, ki volt a BCC: mezőben
Ha a Címzett: mezőben nincs bejegyzés, csak a Titkos másolatban: akkor a levél az összes BCC címzettnek elküldésre kerül, és a levél a címzetteknek "nem nyilvános címzetteknek" vagy hasonló megfogalmazásban jelenik meg. a fogadó e-mail programot.
Különleges megjegyzés a Google-felhasználók számára
A Google IMAP levelezőfiókok eltávolítják a Titkos másolat listában szereplő neveket az elküldött mappából. Ennek eredményeként a feladó – i.e. Ön – nem lesz nyilvántartva arról, hogy kinek küldték el az e-mailt. Ha feljegyzésre van szüksége arról, hogy kiket helyezett el egy e-mailben, akkor ezt manuálisan kell rögzítenie az e-mail elküldése előtt. Ez csak a Gmail szolgáltatása.
A bejegyzések kiválasztása a címjegyzékből
A Thunderbird felkínál egy írási lehetőséget, ha jobb gombbal kattint egy névjegyre a listában.
Ez hasznos, ha csak egy e-mailt szeretne küldeni, de hiábavaló, ha több embernek is el kell küldenie a levelet. Van azonban egy ritkán használt billentyűkombináció, amelyet az operációs rendszer támogat, amely lehetővé teszi több bejegyzés kiválasztását egy listában, például a címjegyzékben:
A gombot lenyomva tartva CtrlParancs gombbal több bejegyzést is kiválaszthat, egérkattintásonként egyet. Ha a listában egy már kiválasztott bejegyzésre kattint, akkor az adott elem kijelölése megszűnik.
Ezen kívül lehetőség van a Shift billentyű használatára. Ha lenyomva tartja a Shift billentyűt, akkor az egérkattintások között minden a listában található.
A Shift és a kombináció használatával CtrlParancs Ugyanebben a műveletben a megfelelő időpontban lenyomott billentyű megváltoztatásával nagyon hatékonyan használhatja fel az idejét a kiválasztott lista finomhangolása közben.
A bejegyzések kiválasztása a kapcsolattartó ablakból
Amikor az Írás, Továbbítás vagy Válasz gombra kattint, a Thunderbird egy kompozíciós ablakot nyit meg. A levélírási ablak egyik jellemzője, hogy tartalmaz egy Névjegyek oldalsáv panelt, amelyből a címjegyzék összes bejegyzése látható. Ezt a panelt az F9 billentyűvel vagy a kompozíciós ablak Nézet menüjével lehet be- és kikapcsolni.
Egyszerűen dupla kattintással, vagy a panel alján található gombok segítségével kiválaszthat bejegyzéseket ebből a panelből
vagy az egér jobb oldali gombjával vagy a Ctrl és Shift billentyűkkel kiválasztott bejegyzésekre kattintva, majd a menüből kiválasztva egy úti célt.
Miután kiválasztotta a hozzáadási lehetőséget, a címek felkerülnek a címzettek listájára a levél tetején, címzettenként egy sorral.
Az oldalsávról egyetlen névjegyet vagy több névjegyet is áthúzhat bármelyik címmezőbe. Az itt leírt többi módszertől eltérően ez több névjegyet illeszt be egyetlen címmezőbe, de vegye figyelembe, hogy a névjegyek a címzettenkénti egysoros formátumban lesznek értelmezve, ha beírja az Entert a címzési mezőbe.
bűvész_római a "vakmásolat" fogalmában, megtanuljuk, hogy ne csináljunk hülyeségeketMeglepő módon sokan, amikor egyszerre több embernek kell e-mailt küldeniük, egyszerűen felsorolják a címeket a "Címzett" mezőben, ez normális, ha ezt az e-mailt kollégáinak vagy barátainak címezték, de ha levelet küldenek egy csoportnak. ügyfelek közül, így mindenkinek megmutatja a többi címzett címét, lényegében felfedve a címbázisát.
Ügyfeleinek csak továbbítaniuk kell ezt a levelet a versenytársának, és az Ön elérhetőségei azonnal kiszivárognak.
Furcsa, de sok korántsem hülye ember meglepődik, amikor megtudja, hogy ha sok címzettnek kell levelet küldenie, hogy ne tudjanak egymásról, akkor ehhez van egy „Bcc” mező.
Például a mail.ru esetében ez így fog kinézni:
És még egyszer röviden:a címeket a „címzett”-ben jelölte meg - mindenki láthatja, hogy kinek küldte a leveleket, „vakmásolat”-ban van feltüntetve - mindenki azt hiszi, hogy a levél csak neki szól.
És minden címzett kap egy levelet, ahol a „címzett” mezőben ott lesz csak a címét . Más programok esetén, ha nem találja a BCC-t, kérjen meg valakit, hogy mutassa meg. Egy másik apró pont, meg kell adnia egy címet a „to” mezőben; a legtöbb program vagy levelezőszerver nem engedi, hogy e paraméter nélkül levelet küldjön.
Tehát, ha ajánlatokról, hírekről van szó ügyfelei egy csoportjának – itt egyértelmű a vakmásolat használatának gyakorlata, el kell rejtenie címbázisát. Egy érdekes pont a kollégáknak szóló levélküldéssel kapcsolatban, itt javasolt a helyzetnek megfelelően eljárni, például levelet küldeni javaslatok küldésére (például az ügyfélszolgálat javítása érdekében), és ha minden kolléga látja, hogy más emberek kapták ugyanazt a levelet, akkor valószínűleg nem fognak válaszolni - másokra támaszkodnak, ami azt jelenti, hogy rejtett másolatot kell használnia. Ha ezt a parancsot végrehajtják, akkor például a kollégája főnökének feltüntetése egyszerűen csodákat tesz, és az Ön megrendelése teljesül.
Külön probléma a beszállítókkal. Egyrészt az összes címzett feltüntetésével a másolaton azt kell mutatnia a szállítónak, hogy van választási lehetősége, és jó árakat kell kínálnia. Másrészt a vezető, aki megkapta a levelét, látva, hogy nem csak neki küldték, nagy valószínűséggel „hűvösen” fogja kezelni kérését. Személy szerint véleményem szerint a beszállítók esetében rejtett másolatot kell használni, legalábbis az üzleti titkok védelme érdekében, de inkább a beszállító vezetőjével való jó kapcsolat érdekében.
Olvasható egy közelmúltban egy szakember tévedésének esete, amikor az összes címzett más címzettet látott: Smack mindenkinek ebben a chatben, valóban tiszteletreméltó emberek voltak ott - igazgatók, de még így is sokan kaptak válaszként spamet.
Nos, mint mindig, szívesen fogadjuk a hozzászólásokat.
Az utóbbi időben időszakonként találkozom ilyen bejövő üzenetekkel, és egy ilyen üzenet tőlem nem ilyen és olyan helyre került, hanem a levél törzse tele van valamiféle eretnekséggel, linkekkel stb. Minden rendben lenne, de én még nem küldtem oda ilyen üzeneteket, és most látom először a tartalmukat.
Mi a hamisítás és hogyan működik
Az alábbi szöveg innen származik.
Ha hibaüzenetet kap, amikor üzenetet küld fiókjából, a Spam mappában olyan üzeneteket talál, amelyekben Ön szerepel feladóként, vagy választ kap egy olyan üzenetre, amelyet nem Ön küldött, akkor hamisítás áldozata lehet. A hamisítás a kimenő levelek visszaküldési címeinek hamisítása az üzenet valódi eredetének elrejtése érdekében.
Postai üzenetküldéskor általában a borítékon feltüntetik a visszaküldési címet. Ezzel a címzett megállapíthatja a feladó személyazonosságát, a posta pedig szükség esetén visszaküldheti a levelet a feladónak. Azonban semmi sem akadályozhatja meg a feladót abban, hogy a saját címe helyett valaki más címét adja meg. Ez azt jelenti, hogy egy másik személy küldhet levelet, és használhatja az Ön visszaküldési címét a borítékon. Az e-mail ugyanúgy működik. Amikor a szerver e-mailt küld, megadja a feladót, de a feladó mező hamisítható. Ha valaki félrerakta a címét egy üzenetben, kézbesítési probléma esetén az üzenetet akkor is visszaküldjük Önnek, ha nem Ön küldte el.
Ha olyan e-mailre kap választ, amelyet nem az Ön címéről küldtek, ennek két oka lehet.
- A levelet hamisították, és az Ön címe volt feltüntetve a feladó címeként.
- A valódi feladó megadta a visszaküldési címét, így minden választ Önnek küldjük.
Ezen opciók egyike sem jelenti azt, hogy valaki más hozzáfért fiókjához, de ha aggódik a biztonsága miatt, megtekintheti a legutóbbi hozzáférések előzményeit. A beérkező levelek oldalon görgessen lefelé, és kattintson a hivatkozásra további információ a vonal mellett.
Utószó
Szóval ne ess pánikba – csak arról van szó, hogy a támadók ismét horoggal vagy szélhámossal próbálnak minket elcsábítani mindenféle baloldali link segítségével. Az ilyen leveleket természetesen figyelmen kívül hagyjuk és a hivatkozásokra kattintás nélkül töröljük.
Egyébként soha nem szabad megfeledkezni róla.
PS: Figyelmeztető kérdések: „további információk” és „legutóbbi műveletek a fiókban” témában - csak a postafiókokra vonatkozik Gmail.
szia habr! Ebben a megjegyzésben úgy döntöttem, hogy érintem a hamis e-mailek elleni védelem témáját (e-mail-hamisítás, hamisított e-mail). Olyan levelekről lesz szó, amelyekben a feladókra vonatkozó információkat valamilyen módon meghamisítják. A címzett lát egy levelet, amelyet állítólag egy megbízható személy küldött, de valójában a levelet egy támadó küldte.
Az utóbbi időben egyre gyakrabban hallunk ügyfeleinktől, és éppen ismerősöktől a hamis levelek problémájáról. Ez a probléma nem csak aktuális, de úgy tűnik, hogy egyre nagyobb lendületet kap. Íme egy igaz történet egy baráttól, aki közel került ahhoz, hogy dollárban kifejezve négy nullát veszítsen. A cég angol nyelvű levelezést folytatott egy külföldi céggel drága speciális berendezések beszerzéséről. Eleinte árnyalatok merültek fel barátunk oldalán - meg kellett változtatni a feladó (vevő cég) fiókadatait. Nem sokkal később, az új adatok sikeres egyeztetése után a berendezés szállítója is tájékoztatott a címzett (eladó cég) számlaadatainak módosításáról. De a címzett adatainak megváltoztatásáról szóló levelek már olyan támadóktól származtak, akik sikeresen lecserélték a feladó címét. Némi általános zűrzavar hátterében, amelyet súlyosbított az a tény, hogy mindkét fél nem beszélte a levelezési nyelvet, szinte lehetetlen volt észrevenni a betűk helyettesítését. Azt is meg kell jegyezni, hogy a támadók szorgalmasan másolták a levelekben szereplő stílusokat, betűtípusokat, aláírásokat és fényképeket. Hogy pontosan milyen információk szivárogtak ki az ügyletről - valószínűleg az e-mailes levelezés veszélybe került. Egy héttel a jelen cikkben tárgyalt tranzakció végleges jóváhagyása előtt egy trójai levél érkezett egy barátom postáján, számla formájában egy *.exe archívumban. Amikor a levél megérkezett, a vírusirtó nem kapta el a kártevőt, és egy ideig sikerült is „működnie” a számítógépen, sőt pár társát is segítségül hívta.
Néhány nappal később frissítették a vírusvédelmi szignatúrákat, eltávolították a kártevőt és annak testvéreit, de addigra a levelezés már beékelődött, a feladót meghamisították, a pénz pedig valaki más számlájára került.
Ebben a példában a feladó címének cseréje rendkívül egyszerű módon történt. Valódi címeket nem teszünk közzé, de adunk egy hasonló példát.
A feladó helyes címe: [e-mail védett]
Hamis feladó cím: [e-mail védett].
A támadó e-mail fiókja tartalmazta a „best@bestofall” nevet és a „.com” vezetéknevet. A barát a levelezés egy részét egy mobileszközről folytatta, amelynek levelezőprogramja csak a feladó vezeték- és keresztnevét jelenítette meg a feladó mezőben. És minden mobil e-mail kliens ezt teszi. Ezért ebben az e-mail kliensben a bejövő levelet a best@bestofall „space” .com címről származónak tekintették. Ami nagyon hasonlít az eredetire. Az alábbiakban a támadó levele látható, alatta pedig egy jogos levél a Yandex.Mail felületen:
Az Outlookban a támadó levele is nagyon hasonlított az eredetihez, ha nem nézed alaposan, lehet, hogy észre sem veszed a hamisítványt.
Mindenre fény derült, amikor a beszállító felhívott és megkérdezte: „Veer from mai mani?” Egy barát szerencséjére az eredetileg aláírt szerződés adatainak (címzett és feladó) kétszeres változása miatt a $$$$$ végül nem került jóváírásra a támadók számláján, hanem a címzett bank tranzitszámláján ragadt. , és vissza lehetett őket küldeni.
A vállalatok világszerte jelentős veszteségeket szenvednek el az e-mail támadások miatt (). Így 2013 októbere és 2015 augusztusa között a vállalatok vállalati e-mailjeinek kompromittálásából eredő teljes veszteség 1,2 milliárd dollárt tett ki világszerte. A hamis levelekkel történő támadások pedig a vállalati levelezőrendszerek elleni támadások leggyakoribb típusai.
Különös figyelmet fordítanak azokra a támadásokra, amelyek során a támadó hamis e-mailt küld egy magas rangú vállalatvezető nevében. A levél szövegében a támadó azonnali választ, vagy valamilyen sürgős reakciót követel egy alkalmazotttól vagy vállalati alkalmazottak csoportjától. Például megkövetelheti, hogy egy levélre bizalmas információ elküldésével válaszoljon. Ez adatszivárgáshoz vezethet. Vagy a támadó nagy összeg sürgős banki átutalását követelheti. A leírt forgatókönyvekben a munkavállaló nyomást érez: egy magas rangú vezető azonnali intézkedést követel. Ez a tény növeli a támadás sikerességének valószínűségét. Emellett a támadást social engineering módszerekkel végzett felderítés előzheti meg a levél szövegének leghatékonyabb megfogalmazása és a hamis levelet kézhez kapó alkalmazottak célcsoportjának legpontosabb azonosítása érdekében. Ez a megközelítés jótékony hatással van a támadás sikerére is.
Annak érdekében, hogy megértsük a feladó címének meghamisításának mechanizmusát, emlékezzünk vissza az SMTP protokollon keresztül továbbított e-mail szerkezetére. Az e-mail borítékból, fejlécekből és üzenettörzsből áll. A feladóra vonatkozó információkat a boríték tartalmazza. Ezeket az információkat az SMTP parancsból származó levél generálja, és közvetlen hatással van az üzenettovábbítási folyamatra, amint áthalad a levéltovábbítási ügynök (MTA) levelezőszerverén. Néhány üzenet fejlécében azonban a feladóra vonatkozó információk is szerepelnek, mint például a „From:”, „Return-Path:”, esetleg „Reply-To:”. A „Feladó:” fejlécnek nem kell egyeznie a levélborítékba írottakkal, és valamilyen „barátságos nevet” (baráti név, baráti név) jelenthet. A „Return-Path:” fejléc a feladót másolja a borítékból. A „Reply-To:” fejléc tartalmazza a válasz címét. A fejlécek fontosak az e-mail kliens számára (például MS Outlook), a megfelelő mezők a fejlécek alapján kerülnek kitöltésre.
Nézzünk egy példát az SMTP-parancsokra a „From:” és „Reply-To:” hamis fejlécekkel ellátott levél küldésére. Csatlakozás az Exchange levelezőszerverhez telnet használatával:
Telnet 10.1.2.3 25 220 Exchange Microsoft ESMTP MAIL A szolgáltatás készen áll: 2016. október 26., szerda, 10:28:00 +0300 helo 250 Exchange Üdvözlet a következőtől: [e-mail védett] 250 2.1.0 Küldő OK rcpt a következő címre: [e-mail védett] 250 2.1.5 Címzett OK adatok 354 Levélbevitel indítása; végére
Ebben a példában valós címről küldünk [e-mail védett] levelet, de a „Feladó:” fejlécben feltüntetjük a cégvezető nevét és címét, a „Válasz” fejlécben pedig a mail.yandex címet, ahová a figyelmetlen dolgozó bizalmas információkat küld. Ennek eredményeként az Outlook levelezőprogramjában a levél így fog kinézni:
És ha a „Válasz” gombra kattint, a címzett címe automatikusan kitöltésre kerül:
Ahogy az előző példából is látható, hamis e-mail küldése nem túl nehéz, ha a levelezőszerver nincs védve. A legrosszabb esetben a levél borítékában lévő érték is helyettesíthető egy legitim értékkel. Ha az e-mail törzsét gondosan és a social engineering eredményeit felhasználva állítják össze, a hamis e-mailek azonosítása egyre nehezebbé válik a végfelhasználó számára. A helyzet még rosszabb a mobileszközöket használók esetében. A mobilitás fogalma azt feltételezi, hogy minden műveletet gyorsan, „menet közben” hajtunk végre, még egy kis képernyőn is, anélkül, hogy az apró részletekre/ellentmondásokra figyelnénk. Egyébként a külföldi céggel kötött üzletről szóló példában egy baráti ügylet is tartalmazta a „mobilitás” tényezőt. A levelezés egy része mobileszközről zajlott, az e-mail kliens csak a feladó vezeték- és utónevét jelenítette meg a feladó mezőben, de a teljes e-mail címet elrejtette.
Nincs egyetlen módszer a hamisított e-mailek kezelésére. Az ilyen típusú támadások elleni védelem integrált és többszintű megközelítést igényel. Megpróbálom kiemelni a hamis e-mailek elleni küzdelem főbb módjait:
- Szűrés a küldő szerver hírneve alapján.
- Szűrés a küldő szerver DNS-rekordjainak ellenőrzése alapján.
- Szűrés a feladó tartomány DNS-rekordjainak levélborítékból történő ellenőrzésén alapul.
- Szűrés SPF-rekordellenőrzések alapján.
- DKIM alapú szűrés.
- DMARC alapú szűrés.
- Szemcsés szűrők manuális létrehozása.
A 4-6. módszer segít leküzdeni a pontos feladó hamisítást, vagyis azokat a helyzeteket, amikor a támadó egy levél fejlécében egy meghamisított feladót jelez, egészen egy jelig.
A 7. módszert olyan esetekben kell alkalmazni, mint például a cikk elején a külföldi céggel folytatott levelezésről szóló példában, amikor a levél fejléce úgy módosul, hogy az a valódi feladóhoz hasonlítson. Ugyanakkor a hamisított levél fejléce továbbra is eltér a valódi feladó fejlécétől, amely lehetővé teszi az ellenőrzések megkerülését a 4-6 módszerrel.
Tekintsük részletesebben a felsorolt módszereket.
1. Szűrés a küldő szerver hírneve alapján. Ha a vállalati levélvédelmi rendszer kiváló minőségű feladói hírnév-adatbázist biztosít, akkor a kéretlen levelek és bármilyen rosszindulatú levelezés terjesztőinek jelentős százalékát már a TCP-munkamenet létrehozásának szakaszában ki tudjuk szűrni anélkül, hogy belenéznénk az üzenet törzsébe vagy borítékába. levél. Ez a megközelítés jelentősen megtakarítja a rendszer erőforrásait. Amint a küldő megpróbál TCP-munkamenetet létrehozni a 25-ös porton, a biztonsági rendszer meghatározza a küldő IP-címének hírnevét, és döntést hoz.
Cisco ESA példa. Hírnév szűrés.
Néhány konkrétum a Cisco ESA példáján keresztül. A megoldás a Sender Base hírnévadatbázisát használja. Látjuk, hogy a hírnévszűrés segít megállítani a rosszindulatú e-mailek körülbelül 80%-át. Ezen túlmenően a megoldás bevezetése és karbantartása terén szerzett sokéves tapasztalat alapján elmondhatom, hogy a Cisco ESA hírnévszűrés hamis pozitív üzeneteinek száma nullára szokott csökkenni.
Az alábbiakban összefoglaljuk szervezetünket:
A feladó hírnevétől függően a Cisco ESA nemcsak úgy dönt, hogy eldobja-e a levelet, vagy tovább ugorja, hanem meghatározza a levél feldolgozásának további forgatókönyvét is. A különböző hírnévértékekre különböző irányelveket alkalmazhatunk:
2. Szűrés a küldő szerver DNS rekordjainak ellenőrzése alapján. Az e-mail üzenetek feladójának megfelelően regisztrálva kell lennie a DNS-ben. A feladónak érvényes PTR-rekorddal és A-rekorddal kell rendelkeznie. A feladót helyesen kell megadni az SMTP HELO parancsban. A tömeges spam és rosszindulatú programok küldésekor a támadók folyamatosan változtatják a küldő szerverek IP-címét. A címek minden nap és még gyakrabban változnak. A szükséges rekordok regisztrálása a DNS-ben nehéz, sőt lehetetlen. Ezért sok spam és rosszindulatú üzenet terjesztője figyelmen kívül hagyja ezeket a követelményeket, és ennek megfelelően lehetővé válik a DNS-kritériumok szerinti szűrés.
Cisco ESA példa. A feladó IP-címének DNS-ellenőrzése.
Nézzük meg a DNS-ellenőrzéseket a Cisco ESA segítségével. A TCP-munkamenet létrehozásakor a következő DNS-ellenőrzések kerülnek végrehajtásra a küldőn:
- PTR rekord meglétének ellenőrzése. A PTR rekordnak egyedinek kell lennie, és a feladó helyes kanonikus gazdagépnevét kell visszaadnia.
- Az első lépésben talált gazdagépnév A rekordjának meglétének ellenőrzése (a PTR rekord segítségével).
- Annak ellenőrzése, hogy az előző lépésből származó A rekord továbbítási DNS-keresése megegyezik-e a küldő IP-címével.
Szeretném felhívni a figyelmet arra, hogy az ESA az ellenőrzések ezen szakaszában nem ellenőrzi a feladó legitimitását, vagyis nem ellenőrzi, hogy a feladónak van-e joga leveleket küldeni a megadott domainről. Ráadásul ebben a szakaszban sem a levél borítéka, sem a fejléc nem látható. Csak az IP-cím szerinti ellenőrzés működik. Például, ha a mycompany.ru domain levelei a „bal oldali” IP-címről érkeznek, a DNS-ben megfelelő A és PTR rekordokkal, például „smtp.spamer.ru”, az ellenőrzés sikeres lesz, és a levél további feldolgozásra kihagyták. A feladók legitimitásának ellenőrzése más módszerekkel történik (lásd lent SPF rekordok, DKIM, DMARC).
3. Szűrés a küldő tartomány DNS rekordjainak levélborítékból történő ellenőrzése alapján. A feladótól érkező levelek adatai szintén DNS-ellenőrzés tárgyát képezik. Példaként a Cisco ESA használatával egy betűt el lehet dobni, ha:
- A feladó domain információi hiányoznak a borítékból.
- A domain név nincs feloldva a DNS-ben.
- A domain név nem létezik a DNS-ben.
4. Szűrés SPF rekordellenőrzések alapján. SPF – Sender Policy Framework – az elektronikus üzenetek feladóinak ellenőrzésére szolgáló rendszer. A „Feladó szerver DNS-rekordjának” ellenőrzése 2. módszer csak azt jelzi, hogy a szükséges DNS-rekordok (PTR és A rekordok) léteznek a küldő IP-címéhez. Ezek az ellenőrzések azonban nem segítenek meghatározni, hogy a küldő kiszolgálónak van-e joga leveleket küldeni a megadott tartományból. Érdemes megjegyezni, hogy a levelezőszerverek A-rekordjai gyakran tartalmazzák a vállalati domain nevét, például: smtp01.mycompany.ru. Ha ugyanazt a szervert használják levelek fogadására, akkor ugyanaz az A rekord az MX rekordban is szerepel. Feltételezhetjük, hogy ha a mycompany.ru levelet az smtp01.mycompany.ru szerverről küldik, akkor ez a levél nem hamis, ellenkező esetben, ha a levelet az smtp01.anythingelse.ru címről küldik, a levél hamis. Valójában azonban a cégek gyakran nem közvetlenül a levelezőszervereikről küldenek e-mailt, hanem néhány további MTA-szerveren keresztül, például szolgáltatóik szerverein keresztül. Ebben az esetben azt találjuk, hogy a mycompany.ru tartomány levele szervereken keresztül érkezik, például smtp01.provider.com, smtp02.provider.com stb. A küldő szerverek kanonikus nevei nem tartoznak a mycompany.ru vállalati tartományhoz. Hogyan értheti meg ebben az esetben a címzett oldal, hogy a küldő szerverek legitimek-e vagy sem? Ezt a problémát az SPF ellenőrző rendszer oldja meg.
A probléma ismét megoldódott a DNS használatával. Egy speciális formátumú TXT rekordot tesznek közzé a küldő tartományához. Ez a TXT-rekord felsorolja azoknak a szervereknek az IP-címeit, alhálózatait vagy A rekordjait, amelyek levelezést tudnak küldeni, illetve azokat a szervereket, amelyek nem legitim feladók. Az SPF rendszernek köszönhetően a címzett felveheti a kapcsolatot a DNS-sel, és tisztázhatja, hogy a levél küldő szervere megbízható-e, vagy a küldő szerver megpróbál valaki mást kiadni.
Jelenleg nem minden vállalat hoz létre SPF-rekordokat.
5. DKIM alapú szűrés. DKIM – DomainKeys Identified Mail – elektronikus üzenet-hitelesítési technológia. Térjünk vissza a példához az SPF-rekordok megfontolásából, amikor a mycompany.ru cég az smtp01.mycompany.ru és az smtp02.provider.com szolgáltatón keresztül külsőleg küldi el a levelezést. Vannak SPF-rekordok az MTA-hoz, így a mycompany.ru webhelyről ezeken a szervereken keresztül küldött e-mailek ellenőrzése sikeresen megtörténik. De mi van akkor, ha az MTA adatok veszélybe kerülnek, és a támadó képes hamisított e-maileket is küldeni ezeken a szervereken keresztül? Hogyan lehet ebben az esetben hitelesíteni a feladót? A levél hitelesítés segít.
A hitelesítéshez aszimmetrikus kriptográfiát és hash függvényeket használnak. A privát kulcsot kizárólag a küldő szerver ismeri. A nyilvános kulcsot ismét közzéteszi a DNS segítségével egy speciális TXT rekordban. A küldő szerver egy hash függvény segítségével ujjlenyomatot generál az üzenet fejléceiről, és a privát kulccsal aláírja. Az aláírt ujjlenyomat az e-mail „DKIM-Signature:” fejlécébe kerül. Most a levél címzettje a nyilvános kulcs segítségével megszerezheti a dekódolt ujjlenyomatot, és összehasonlíthatja azt a kapott levél mezőinek ujjlenyomatával (a hash funkció ismert). Ha az ujjlenyomatok megegyeznek, az aláírt fejlécek nem változtak az átvitel során, és a levél feladója, aki a „DKIM-Signature:” fejlécet generálta, jogos.
6. DMARC alapú szűrés. DMARC – Domain-based Message Authentication, Reporting and Conformance egy műszaki specifikáció, amely pontosan leírja, hogyan kell felhasználni az SPF- és DKIM-ellenőrzések eredményeit. A DMARC-házirendeket a szokásos módon a DNS használatával teszik közzé egy TXT-rekordban. A DMARC-irányelvek meghatározzák, hogy pontosan mit kell tenni a levéllel a címzett oldalán (kézbesítés, eldobás, karantén), az SPF- és DKIM-ellenőrzések eredményeitől függően. Ezenkívül a DMARC visszajelzést ad a feladótól a címzetteknek. A feladó minden olyan e-mailről jelentést kaphat, amely rendelkezik a feladó domainjével. Az információk tartalmazzák a küldő szerverek IP-címét, az üzenetek számát, a DMARC szabályzatnak megfelelő eredményt, az SPF és DKIM ellenőrzések eredményeit.
7. Szemcsés szűrők „kézi” létrehozása. Sajnos nem minden szervezet használ SPF-et, DKIM-et, DMARC-t az e-mailek küldésekor. Ezenkívül bizonyos esetekben az SPF-, DKIM- és DMARC-ellenőrzések is sikeresek lehetnek, de az e-mailek továbbra is hamisnak bizonyulnak (Cousin domain, Free Email Accounts). Ilyen esetekben a szűrőbeállítások segítenek. A különböző rendszerek szűrési szabályok létrehozására vonatkozó képességei eltérőek. A szűrők különféle támadási forgatókönyvekhez vannak konfigurálva, és a vállalatok levelezőrendszereinek adott szervezetétől függenek. Például egyes cégeknél egy levél kívülről érkezhet ugyanannak a cégnek a küldő domainjével. Bár a legtöbb esetben az ilyen leveleket csak a szervezet határain belül szabad elküldeni.
Inkább a Cisco ESA-ra koncentrálunk, ezért befejezésül meg fogunk nézni néhány példát a szűrők beállítására ezen a megoldáson, valamint a Cisco ESA - Forged Email Detection szoftver 10.0-s kiadásában (2016 júniusában) megjelent érdekes funkciókat. Ez a funkció lehetővé teszi a pontatlan hamis feladók elleni küzdelmet, mint a cikk elején látható példában. Ha érdekel, üdvözöljük a tackle-ben.
Cisco ESA példa. Szűrők.
A Cisco ESA kétféle szűrőt kínál: tartalomszűrőket és üzenetszűrőket. Az előbbiek grafikus felhasználói felülettel vannak konfigurálva, és véges (bár meglehetősen kiterjedt) listát kínálnak a feltételekről és műveletekről. Példa a GUI-ból:
Ha a tartalomszűrők nem elegendőek ahhoz, hogy leírják azokat a feltételeket, amelyek alapján egy betű a szűrő alá kerül, akkor használhatja az Üzenetszűrőket. Az üzenetszűrők a parancssorból konfigurálhatók, reguláris kifejezéseket használnak a feltételek leírására, és lehetővé teszik összetett feltételek létrehozását (például If ((A és B) és nem C) vagy D) ). Az üzenetszűrők a tartalomszűrők előtt dolgozzák fel az e-maileket, és lehetővé teszik részletesebb szabályok létrehozását.
Nézzünk meg néhány feladó hamisítási forgatókönyvet és a megfelelő Cisco ESA szűrőket a támadás leküzdésére.
1. példa A feladóban a szervezet domainjét tartalmazó levelek nem érkezhetnek kívülről. Példa a cisco.com oldalról: link. A példa akkor releváns, ha egy szervezet nem áll készen az SPF és a tartománykulcsok közzétételére a DNS-ben. Ez a példa a következő üzenetszűrőt használja:
MarkPossiblySpoofedEmail: if ((recv-listener == "InboundMail") AND (subject != "\\(Esetleg hamisított\\)$")) // Ha az e-mail kívülről érkezett, és még nincs megjelölve a fejlécben, az e-mail " Lehetségesen hamisított" ( if (mail-from == "@sajatdomain\\.com$") VAGY (header("From") == "(?i)@sajatdomain\\.com") // Ha egy borítékban a feladó tartalmazza a szervezet tartományát, vagy a Feladó fejléc tartalmazza a szervezet tartományát ( strip-header("Tárgy"); insert-header("Tárgy", "$Tárgy (Esetleg hamisított)") ; ) ) // Adja hozzá a „Esetleg hamisított” bejegyzést a „Hamisított” fejléchez
Műveletként más lehetőségek is kiválaszthatók: karanténba küldés, levél eldobása stb.
2. példa A cikk elején megnéztünk egy példát, amikor a levélborítékból származó levél nem volt hamis ( [e-mail védett], vagyis a támadó helyes címét írja be), de a Feladó fejléc hamis címet jelzett ( [e-mail védett]). Ugyanakkor semmi sem akadályozza meg a támadót abban, hogy SPF-et és tartománykulcsokat állítson be a DNS-ben a spoofed.ru tartományhoz. Azt kapjuk, hogy a hamis e-mail átmegy az SPF- és DKIM-ellenőrzéseken. Ezenkívül az SPF- és DKIM-ellenőrzések sikeresek lesznek, ha a támadó ingyenes leveleket használ (ingyenes levelezési fiókok – gmail.com, mail.ru stb.).
Ezzel a helyzettel úgy küzdhetünk, hogy ellenőrizzük a feladó és a Feladó fejléc értékeinek egyenlőségét. Érdemes azonnal lefoglalni: az RFC általában nem követeli meg, hogy a feladó levél egyenlő legyen a Feladóval. Ezért ilyen szűrőt csak egyes feladókra kell alkalmaznia.
A Cisco ESA-nak jelenleg (2016. november) van egy korlátja: a mezőértékeket nem lehet egymással összehasonlítani, vagyis nem lehet egyszerűen csak írni, ha a levél innen: != fejléc (From). A probléma más módon is megoldható. Elkészítjük a feladónevek szótárát, a Spoofed_senders, amelybe beírjuk a hamisításra fogékony feladókat. A szűrőben beállítunk egy feltételt: ha a feladó levele nem tartalmaz feladót a szótárból, és a Feladó fejléc tartalmaz feladót a szótárból, hajtsa végre a műveletet. Az üzenetet karanténba helyezheti vagy elvetheti, de a Cisco azt javasolja, hogy írja be a módosított From fejléc értékét egy új X-Original-From fejlécbe, és távolítsa el a Feladó mezőt. Ebben az esetben a Cisco ESA automatikusan generálja a Feladó fejlécet a mail from értékéből. Példa egy ilyen szűrőre:
SpoofedSendersFilter: if (header-dictionary-match("Spoofed_Senders","From", 1)) AND (NOT (mail-from-dictionary-match("Spoofed_Senders", 1))) // Ha a Feladó mező tartalmaz nevet a szótárból , és a mail from value nem tartalmaz nevet a szótárból ( insert-header("X-Original-From", "$From"); strip-header("From"); ) // Hozza létre a X-Original-From fejléc és törlés a fejlécből
3. példa A támadók a feladó címeihez hasonló címeket, úgynevezett „unokatestvér domaineket” és „unokatestvér-címeket” használnak. Például cím [e-mail védett] helyettesíti [e-mail védett]. A cbc.ru domain esetében az SPF és a tartománykulcsok generálódnak a DNS-ben, így a levelek sikeresen átmennek a megfelelő SPF és DKIM ellenőrzéseken, és a levél címzettje ismerős feladót lát. Nehezebb leküzdeni egy ilyen helyettesítést. Az előző példában szereplő Spoofed_senders szótárba be kell írnia a feladónevek és a domain nevek minden hasonló változatát, ami aligha lehetséges.
Az ilyen típusú küldőhamisítás elleni küzdelem érdekében a Cisco ESA az AsyncOS 10.0 kiadásától (2016. június) bevezetett egy érdekes „Forged Email Detection” funkciót. Először is létrejön a feladónevek szótára (a példákban a FED szótár nevét használjuk), az előző példához hasonlóan, amelybe beírjuk a hamisításra hajlamos feladókat. Ez a szótár a feladók nevéből, nem pedig a postafiókok nevéből készül. Vagyis inkább Olivia Smith-t kell írni [e-mail védett]. A hamisított e-mail észlelési rendszer a Feladó fejlécet összeveti a FED szótárban szereplő nevekkel, és megadja annak valószínűségét (1-től 100-ig), hogy a feladó hamisítottnak tekinthető.
Például, ha a szótár tartalmazza a „John Simons” szót, és a Feladó fejléc tartalmazza [e-mail védett], a rendszer 82-es hamisítási valószínűséget jelenít meg. Ha a Feladó fejléc tartalmazza [e-mail védett](azaz ugyanaz a név, de más domain), a rendszer 100-as hamisítási valószínűséget ad.
A hamisított e-mail-észlelés tartalomszűrőkkel vagy üzenetszűrőkkel konfigurálható. Az alábbiakban egy képernyőkép látható a tartalomszűrő beállításairól:
Meg kell adni a szótár nevét és azt a küszöbvalószínűségi értéket, amely után a feladót hamisítottnak tekintjük. Ehhez a feltételhez bármelyik elérhető műveletet kiválaszthatja (eldobás, karanténba küldés, levél tárgyának módosítása stb.). Ezenkívül van egy új további művelet a hamisított e-mail észleléséhez: cserélje ki a Feladó fejléc értékét a feladótól származó levél értékére. Ez a művelet nem kínál semmilyen lehetőséget:
Következtetés
Az e-maileket érő feladói hamisító támadások sajnos mindennaposak. Egy ilyen sikeres támadásnak pedig rendkívül katasztrofális következményei lehetnek mind az egyes egyénekre, mind a megtámadott szervezet egészére nézve. Jelentős anyagi veszteségek és bizalmas információk kiszivárogtatása lehetséges. Remélem, ez a cikk segít megérteni a hamis e-maileket használó támadások anatómiáját és a védekezési módszereket. A példákban a Cisco ESA megoldását használtam, azonban a cikkben említett védelmi eszközök más vállalati e-mail védelmi rendszereken is megvalósíthatók.
