E-mail: ahol a betörések kezdődnek (x)

Hirdetés

Az e-mail az internet őskorának szülöttje, biztonsága a múlt század szintjén ragadt. Ha érdekel, hogy mi kellene ahhoz, hogy a levelezés valóban biztonságos legyen, regisztrálj meetupunkra! További részletek »
 

( babo v | 2022. 11. 16., sze – 19:22 )

Alapvető változást hozna, ha a feleadóban csak olyan domain szerepelhetne, amilyenből indul a levél. Persze ez azt is jelentené, hogy komplett területek (tömeges mail küdő stb.) élete változna meg és válna követhetőbbe. A spamek és becsapós levelek száma drasztikusan csökkenhetne ennek eredményeképpen. - gondolom én 

Más, de példaként ide kapcsolható: IP címre van egy ajánlás, mely szerint forrásIP-szűrést illendő alkalmaznia a szolgáltatónak. Csak olyan forráscímmel engedhet ki forgalmat a nagy közösbe, amely az AS-eiben szerepel.
Sajnos rengetegen nem tartják ezt az illemszabályt --> UDP erősítéses támadás ezért sok szolgáltatótól indítható.

Igen, email esetén is ez lenne kívánatos, DNS SPF rekordra bekapcsolni a szűrést a levélfogadó szerverben és a küldő SMTP szerverek üzemeltetői kivétel nélkül állítsák be az SPF-et a DNS zónafájljukban.
Jelenleg a probléma az, hogy ha te beállítod fogadásra az SPF szűrést, a kiscégek felétől el lesz dobva a levél. Ha pedig nem állítod be, akkor meg ömlik a sok fake spam.

Fogadáskor kell az SPF szűrés. Alábbfentebb írtam, hogy a Google is nekiállt februártól komolyan venni. Épp ma láttam egy gugli felhős fiókban ekkkoooora sárgával figyelmeztető emailt, amikor egy rendes kontakt gmailes-es feladóját kiemelte. Megnéztem és valóban, valami saját SMTP-ről küldött emberünk, aki ájtivel foglalkozik..., gmail.com -os emailt. Szóval a szigort mindenhol be kéne tartani.

( zeller | 2022. 11. 16., sze – 22:19 )

Az SMTP, mint olyan... Olyan. Nem kicsit - nagyon.

Remek technikák vannak erre, lásd még SPF meg DKIM meg ilyesmik, csak ehhez komolyan kéne őket venni a fogadó oldalon, és nem hanyatthomlok vigyázzállásban elnézést kérve kikapcsolni, amikor a főnök nem kapja meg a szuperfontos levelet a bénán emailező partnertől. Ha bármi ellenvetése van, akkor távozni kell, azzal, hogy majd amikor klikkel egy jóféle malware-re, és beszippant valamit a teljes cég, akkor majd talán észre tér.

Rendszeresen látom, hogy hanyatthomlok very agile módon rohantak felhőbe egyesek, és még a stepbystep képernyőkön sem sikerült végigmenni, hiszen kapjuk az Ügyféltől az ívet, hogy mennyire fontos email nem jöttt át. 90%-ban vagy feketelistán vannak a küldők (többön...), vagy sikerült az onsite mailszerveren hagyni a -all SPF policy-t. Azért ennyire nem kéne rohanni a dolgokkal.

Az a szerencsénk, hogy a Google elkezdte az év elején komolyan venni, és sárgázza, meg visszadobálja a maileket SPF probléma esetén.

A másik probléma a végpontvédelem, illetve a PEBKAC, mert ha a kedves felhasználó felnyal valami csodát (nem kell ehhez email, csak egy kósza weblink valahonnan, ami jajjdecuki). Ha sikeres a malware támadás, akkor csodálatosan felporszívózzák az összes email beállítását, és rossz esetben az összes adatát szépcsöndben. Pláne akkor, hogy ha ki sem kapcsolja melóidőn kívül a gépet vagy esetleg suspendeli, hiszen reggel akár 30mp is sok lehet...

> Az a szerencsénk, hogy a Google elkezdte az év elején komolyan venni

igen, de jo lenne ha az o365 is csatlakozna, akkor talan hatasa is lenne... meg ha csak a -all vegu spf-et fogadnak el (dkim hianya eseten), nem mindent.

a masik gond, hogy sok levelezo (pl. outlyuk) nem is mutatja az email cimet a feladonal, csak a nevet. tehat siman bekuldhetnek adathalaszt a titkarnonek a fonok nevevel valami tok random, de spf/dkim helyes email cimrol/domainrol, ugyse latja.

( wladek1 | 2022. 11. 21., h – 10:29 )

Egy dolgot nem latok soha, sehol. Az alternativakat. 

  • Maga az SMTP/IMAP sem rendelkezik valos, mindenki altal ismert, elerheto es hasznalhato alternativakkal
  • Ezen belul  a "B+ wladek, most varok egy levelet Kuala Lumpurbol es nem erkezik meg, ezen tizmilliokat bukhatunk" lekezelese sem irrelevans...:)

Error: nmcli terminated by signal Félbeszakítás (2)

Természetesen az az alternatíva, hogy be kell regisztrálni valami csúcstechnológiás kollaborációs platformra, ami pont addigra lesz obsolete, mire átmigráljátok rá a tízezer-százezer fős gárdát.

Így aztán ugyanannál a cégnél lesz Skype4B, Teams, Slack, Zoom, stb., de igazán haladó helyeken lehet department szinten is engedni/tiltani egy-egy szolgáltatást. Például az IT-ről kivezetheted a Skype-ot, mert mégiscsak nekik kellene először tesztelni az új megoldásokat, de a Teams-t még ne add oda bizonyos mission critical üzletágaknak, mert nem teszteltük rendesen, szóval ha a business kérdezni akar az IT-tól, akkor legyen nekik egy helpdesk chatbot. Zoomon tiltsd le a chatet, mert nem secure, és máris 0 db olyan platform lesz, amin a business és az IT egyszerre tud chatelni és képernyőt megosztani. A Slack pedig legyen csak a marketing&társaié, akik külsős ügynökségekkel dolgoznak.

Innen már csak azt kell megoldani, hogy megbeszéljétek, ki melyik platformon érhető el, azt majd átmenetileg megoldják emailben, de van itt ez az új platform, ami majd... goto 10.

Es mindemellett a partnerekkel torteno kapcsolattartas meg mindig problemas.
Nincs megoldas pl az e-szamlak kuldozgetesere sem. Egyszeruen annyi sebbol verzik a dolog, hogy inkabb azon kellene elgondolkozni, mit lehet tenni meg az e-mail fenntarthatosaga teren. Majdnem ugyanannyira nem lehet kivaltani, mint pl a DNS -t.

Error: nmcli terminated by signal Félbeszakítás (2)

Akkor is kérdés, hogy mi olcsóbb/egyszerűbb: új rendszert összerakni vagy a meglévőt fejleszteni. Az email esetén nagy szó, hogy lényegében szabványos. Egy új esetén alakulhat ez másként. Tekintve, hogy egy egyszerű SPF jellegű beállítás is lassan megy át, hogy egy teljesen új rendszernek mennyi idő kellene. Főleg, ha kompatibilis: mi lenne az előnye? A spam&co valószínűleg pont ugyanúgy megérkezne.

SMS és push notification spam is létezik. Egyébként ha már káros tartalom : egy nyomorult weboldal megtekintése a betoltes mellé 5 kattintás. Nem kell e-mail a veszélyes élethez, elég egy clickbait cím. Kompatibilitás: próbáld ki : nem kapsz e-mail értesítést semmiről, mert bizony te a YetAnotherMessagingProtocol - t használod kizárólag. 

Error: nmcli terminated by signal Félbeszakítás (2)

Ugyanazt állítjuk, én csak arra reflektáltam, hogy igen, sok a probléma ("annyi sebbol verzik"), de elsősorban nem azért nem lehet kiváltani, mert annyira elterjedt, hanem egy másik rendszerrel javarészt ugyanezek a problémák ismét előjönnének, azaz kvázi elölről lehetne kezdeni az egészet, mint pl spamek elleni védelem. Tehát nem az email "fenntarthatósága" a kérdés, hanem a fejlesztése. Lásd SPF&Co.