Levelek hamisítása
Helló habr! Ebben a cikkben úgy döntöttem, hogy megérintem a hamis e-mailek elleni védelem témáját (e-mail spoofing, hamis e-mail). Olyan levelekről lesz szó, amelyekben a feladókról szóló információk valamilyen módon kovácsolhatók. A címzett egy látszólag megbízható személy által küldött levelet lát, de valójában a támadó elküldte a levelet.
A támadó e-mail fiókja tartalmazza a "best @ bestofall" nevet és a ".com" vezetéknevet. A levelezés egy része olyan mobileszközről volt, amelynek e-mail kliense csak a feladó nevét és vezetéknevét mutatta a feladó mezőjében. És így minden mobil e-mail kliens. Ezért a bejövő levél ebben a levélkliensben a legjobb @ bestofall "blank" .com-ból származik. Ami nagyon hasonlít az eredetihez. Az alábbiakban a támadó levele olvasható, és a Yandex.Mail felületen:
Az Outlook programban a támadó levele hasonlóan hasonlított az eredetihez, ha nem nézi szét, akkor sem észlelheti a hamisítást.
- Szűrő a küldő szerver hírneve alapján.
- Szűrés a feladó szerverének DNS-feljegyzéseinek ellenőrzése alapján.
- Szűrés a feladó domainjének DNS-rekordjainak ellenőrzése alapján a borítéklevélből.
- Az SPF nyilvántartás alapján végzett szűrés ellenőrzi.
- Szűrés a DKIM alapján.
- Szűrés a DMARC alapján.
- Hozzon létre granulált szűrőket "manuálisan".
A 4-6. Módszerek segítenek a feladók pontos cseréjével foglalkozni, azaz azokat a helyzeteket, amelyekben a támadó a betű fejlécében a pontos helyettesítő feladó felé mutat.
7. A módszer lehet hivatkozni abban az esetben, mint a példában a levelezés a külföldi cég a kezdetektől fogva, amikor az üzenet fejlécét tölti módosítható oly módon, hogy legyen, mint a valódi küldőt. De ugyanakkor, a címsor podmenonnom levél még eltér a tényleges feladó fejléc, amely lehetővé teszi, hogy megkerülje a vizsgálati módszerek 4-6.
Tekintsük a felsorolt módszereket részletesebben.
Példa a Cisco ESA-ra. Hírnév szűrés.
Egy kicsit egyedi a Cisco ESA példáján. A megoldás a Sender Base hírneves adatbázisát használja. Úgy látjuk, hogy a hírnévszűrés segít megállítani a rosszindulatú e-mailek 80% -át a régióban. A megoldás végrehajtásában és fenntartásában szerzett sokéves tapasztalattal azt mondhatom, hogy a Cisco ESA jó hírnév szűrésének hamis pozitívuma nulla.
Az alábbiakban összefoglaljuk szervezetünket:
A feladó hírnevétől függően a Cisco ESA nemcsak úgy dönt, hogy elhagyja az üzenetet, vagy tovább ugrik, hanem egy további szkriptet is meghatároz az üzenet feldolgozásához. A jó hírnév különböző értékeire különböző irányelveket alkalmazhatunk:
Például tekintse meg a DNS-ellenőrzéseket a Cisco ESA használatával. TCP-munkamenet létrehozásakor a következő DNS-ellenőrzéseket hajtja végre a DNS:
3. Szűrés a feladó domain doménjének DNS-feljegyzéseinek ellenőrzése alapján a levél borítékából. Az e-mailben szereplő információk szintén DNS-ellenőrzés alá esnek. A Cisco ESA példáján levél eldobható, ha:
- A feladó domainjére vonatkozó információ nincs a borítékban.
- A domain név nem engedélyezett a DNS-ben.
- A domain név nem létezik a DNS-ben.
Az ilyen típusú ellenőrzések nem különösebben hatékonyak, a szándékosan helytelenül kialakított borítékok leveleit el kell dobni.
Jelenleg nem minden vállalat alkotja az SPF-rekordokat.
5. Szűrés a DKIM alapján. DKIM - DomainKeys Identified Mail - technológia az elektronikus üzenetek hitelesítéséhez. Térjünk vissza a példa a felülvizsgálat SPF-rekordokat, amikor a vállalat mycompany.ru küld leveleket keresztül a külső szolgáltató MTA smtp01.mycompany.ru és smtp02.provider.com. Az MTA-nak van SPF-rekordja, ezért a mycompany.ru e szervereken keresztül küldött leveleket sikeresen tesztelték. De mi van akkor, ha az MTA-adatok veszélybe kerülnek, és a támadó képes lesz hamis e-maileket küldeni ezeken a szerveren keresztül? Hogyan tudom hitelesíteni a feladót ebben az esetben? A betűk hitelesítése megmentésre kerül.
A hitelesítéshez aszimmetrikus kriptográfiát és hash függvényeket használnak. A privát kulcs csak a kiszolgáló számára ismert a feladónak. A nyilvános kulcs újra megjelenik a DNS használatával egy speciális TXT rekordban. A feladókiszolgáló létrehozza az üzenetfejlécek nyomtatását hash függvény segítségével, és a magánkulcs használatával jelzi. Az aláírt ujjlenyomat a "DKIM-Signature:" betű fejlécébe kerül. A nyilvános kulcs használatával az üzenet címzettje megkaphatja a visszafejtett nyomtatást, és összehasonlíthatja a kapott levél mezőinek nyomtatásával (a hash függvény ismert). Ha a nyomtatás megegyezik, az aláírt fejlécek nem változtak át az átvitel során, és a "DKIM-aláírás:" fejlécet generáló levél küldője jogszerű.
7. Hozzon létre granulált szűrőket "manuálisan". Sajnos nem minden szervezet SPF, DKIM, DMARC használja az e-mail küldés során. Ezen túlmenően, egyes esetekben, a vizsgálat SPF, DKIM és DMARC sikeres lehet, de a betűk még mindig hamis (Cousin domain, ingyenes e-mail fiókok). Ilyen esetekben a szűrő beállításai segítenek. A szűrési szabályok létrehozásának különböző rendszerei eltérőek. A szűrők különböző támadási forgatókönyvekhez vannak konfigurálva, és a vállalati levelezőrendszerek megszervezésétől függenek. Például egyes vállalatok a levélen kívül is ugyanazon cég küldő domainjével érkezhetnek. Bár a legtöbb esetben ezeket az e-maileket csak a szervezet peremén kell elküldeni.
Példa a Cisco ESA-ra. Szűrők.
A Cisco ESA kétféle szűrőt kínál: tartalomszűrők és üzenetszűrők. Az első a GUI használatával van konfigurálva, és kínálja a végső (bár meglehetősen kiterjedt) listát a feltételekről és a műveletekről. Példa a GUI-ról:
Ha a tartalomszűrők nem elegendők ahhoz, hogy leírhassák az üzenetnek a szűrő működésébe eső feltételeit, használhatja az Üzenetszűrőket. Üzenet szűrők vannak beállítva a parancssorból, a reguláris kifejezések, hogy leírja a környezetet, és létrehozhat nehéz körülmények (például, ha (((A és B), és nem a C) vagy D)). Az Üzenetszűrők feldolgozzák az üzenetet a Tartalomszűrőkhöz, és lehetővé teszik, hogy több szemcsés szabályt hozzon létre.
Figyelembe kell venni több feladó hamis forgatókönyvet és a megfelelő Cisco ESA szűrőket a támadás leküzdésére.
Akcióként más lehetőségeket is választhat: karanténba küldés, levétel elvetése stb.
Ezt a helyzetet úgy kezelhetjük, hogy ellenőrizzük az értékek egyenlőségét a levélben és a From fejlécből. Azonnal érdemes megemlíteni, általában az RFC abszolút nem követeli meg, hogy a levelek egyenlőek legyenek. Ezért csak néhány küldőre kell alkalmazni ezt a szűrőt.
Például, ha a szótárban van „John Simons”, és úgy tűnik, a From header [email protected], akkor a rendszer valószínűleg hamisított 82. Ha a From header tűnik [email protected] (vagyis az azonos nevű , de egy másik tartomány), a rendszer 100 hamisítás valószínűségét adja.
A kovácsolt e-mailes észlelést a tartalmi szűrők vagy az üzenetszűrők konfigurálják. Az alábbiakban a Tartalomszűrő beállításának képernyőképe látható:
Meg kell adnia a szótár nevét és a valószínűség küszöbértékét, miután úgy véljük, hogy a feladó hamis. Ehhez a feltételhez választhat bármelyik elérhető műveletet (visszadobás, karantén, a levél tárgyának módosítása stb.). Ezenkívül újabb kiegészítő művelet történt a kovácsolt e-mailes felderítéshez: cserélje ki az From fejléc értékét az e-mail üzenet értékéből. Ez a művelet nem kínál semmilyen lehetőséget:
