bardóczi ákos @post.r

Nincs másfél éve, hogy a Facebook elérhető a https://facebookcorewwwi.onion/ címen is a világ legismertebb anonimizáló hálózatán keresztül, a TOR-on keresztül. Sokáig nem volt világos, hogy a Facebooknak miért jó, ha anonim módon lehet bejelentkezni egy olyan közösségi szolgáltatásba, ami nem csak, hogy mindent tudni akar, de bármikor szabályosan igazoltathatja a felhasználót, hogy valóban a valós nevével használja-e a szolgáltatást, egyes államokban mobilos megerősítéshez köti a regisztrációt és így tovább. Lehetett sejteni, hogy miért jó, mostanra pedig eléggé világos lett.

Máig csak saccolható, hogy mekkora adathalmazt használ fel a Facebook, amikor eldönti, hogy egy-egy felhasználónak milyen hirdetéseket jelenít meg, de a megtekintett és lájkolt tartalmakon kívül nyilván szerepe van a bejelentkezés helyének is. A bejelentkezés helye, amit alapesetben az IP-cím alapján saccol meg a rendszer, biztonsági szempontból is fontos: ha például valaki mobilról és asztali gépről egyaránt különböző budapesti ill. magyar hálózatokból jelentkezett be az elmúlt néhány hónapban, az utolsó munkamenetet követően néhány órával hiába adná meg elsőre a helyes bejelentkezési adatait mondjuk Brazíliában, a rendszer jelszólopásra gyanakodna és valamilyen plusz ellenőrzésnek vetné alá a felhasználót a fiók védelme érdekében. Azt pedig tudjuk, hogy a TOR hálózat egyik lényegi sajátossága, hogy a net felé látható IP-cím alapján nem állapítható meg a felhasználó tényleges földrajzi helye, ugyanakkor ezek az IP-címek, amik a TOR hálózat ún. exit-node gépeinek címei és a felhasználók megkapják őket a használat idejére, egyszerű automatizált technikai módszerrel nem különböztethetők meg a mezei IP-címektől. /*más kérdés, hogy sok más alapján meg ordít a látogatóról, ha TOR-felhasználó*/ Most indítottam a TOR portable browserjét, a pillanatnyi IP-címem, azaz az exit-node címe 62.210.37.82, azaz úgy tűnik, mintha egy francia céges hálózatból, céges proxy mögül vagy céges VPN-ről léptem volna be, nem? A Facebook is így látja, teljesen más viszont a helyzet, ha valaki a fenti, .onion-os címen keresztül érkezik, hiszen az kizárólag TOR-on keresztül érkezhet, ennek megfelelően pedig a belépéshez használt IP-címeket már csak össze kellett gereblyéznie a Facebooknak, így alighanem most ők rendelkeznek a legpontosabb és legnagyobb adatbázisról, ami a TOR-os IP-címeket illeti. Hogy mi ennek a gyakorlati jelentősége?

...már jól tudja

Később már ha a TOR-felhasználó nem .onion-os címen keresztül érkezik a Facebook bejelentkező oldalára, hanem simán a fb.com címen, viszont az IP-címe abba azon címek egyike vagy azokba a címtartományokba passzol, amikről korábban igazolódott, hogy a TOR-hálózat építőelemei /*pontosabban szélei, ha úgy tetszik*/, abból sokkal több következtetést lehet levonni, mint elsőre látszik. Egyrészt a Facebook tisztában lesz azzal, hogy a felhasználó valódi földrajzi helye nem az, ami az IP alapján látszik, így a hirdetések megjelenítésénél már nem fogja figyelembe venni. Másrészt a Facebook finomhangolni tudja, hogy a felhasználót mennyire riogassa gyanus bejelentkezési kísérletekre figyelmeztetve, ami pedig a legeslegfontosabb, nagyon sokat tanul azoknak a felhasználóknak az érdeklődéséről, akik TOR-on keresztül érkeznek rendszeresen, hiszen sejthetően éppen ők sokkal fogékonyabbak az anonimitást fokozó technikák, szolgáltatások iránt, így nekik pont ezeket érdemes hirdetni - természetesen később akkor is, amikor már nem TOR-on keresztül kapcsolódnak.

Nem is érdemes nagyon ragozni, hogy a hirdetés annál hatékonyabb, minél célzottabb, márpedig ha a Facebook tudja, hogy a felhasználó helyét nem szabad figyelembe vennie és mindenféle anonimizáló, na meg magánszféra védelmére kihegyezett geekséget tud elé tolni a hirdetéseiben. Azaz sebészi pontossággal fogja tudni, hogy kiknek érdemes ilyesmit hirdetni, mi több, tovább tudja a Facebook vizsgálni azt, hogy milyen érdeklődési trendek jellemzőek a TOR-ozó, azaz önmagukat gyakran anonimizáló felhasználókra.

Alighanem nem én mondtam először, de nagyon igaz: ha valaki alaposan magára akarja vonni a figyelmet, nincs is remekebb módszer, mint az aktuálisan tutimenőnek számító magánszférát védő technikát használnia, rendszerint ész nélkül, mivel még több anonimizáló és PET /*privacy enhancing technology*/ együttes alkalmazása sem ér semmit, ha nem ésszel használják. Másrészt már megint az derül ki, hogy egy tényleg jó VPN-szolgáltató ezerszer értelmesebb megoldás, mint a TOR vagy annak valamilyen klónja. A posztot egyébként egy feltételezés tesztelése után írtam meg, egy kísérleti FB-felhasználóval rendszeresen TOR-oztam, aztán figyeltem, hogy hogyan alakulnak az elém talicskázott hirdetések.

Kép: comicsalliance.com

Mindegy, hogy egy apró feljegyzés elkészítéséről vagy egy többszerzős, sokszáz oldalas könyv megírásáról van szó, elvárjuk, hogy amiben dolgozunk, legyen stabil, ne fordulhasson elő adatvesztés, ezen kívül legyen biztonságos és minél több platformon elérhető. Fura módon a többség a mai napig mégis azokat az eszközöket használja dokumentumok szerkesztésére és írására, amik legfeljebb a 90-es években lehettek a kor igényeinek megfelelőek: megszokásból. Mindegy, hogy milyen alkalmazásról van szó, az ok, ami miatt sokszor nem szoknak át a felhasználók egy megoldásról egy minden téren hatékonyabbra, egyszerűen az, hogy nem akarnak 1-2-3 percet szánni arra, hogy egy új felületet megismerjenek, holott a legprofesszionálisabb szerkesztőalkalmazásokban is rendszerint minden kézre áll, amire szükség lehet, a haladó beállítások pedig megfelelően el vannak rejtve.

Ami elvárható a leírtakon túl konkrétabban egy korszerű szolgáltatástól, hogy támogassa a kétlépcsős hitelesítést, ne fordulhasson elő adatvesztés olyan módon, hogy többszerzős dokumentum esetén valaki véletlenül kivág egy jókora részt a dokumentumból, aminek a korábbi változata nem állítható vissza. Azaz minél jobban támogatnia kell az átlátható verziókövetést, ezen kívül legyen multiplatform, mivel szerkeszteni ugyan érdemben úgyis csak asztali gépen lehet, viszont szükség lehet rá, hogy bármilyen mobileszközön be lehessen húzni az alkalmazást a fellegek’ közül és persze pillanatok alatt lehessen konvertálni bármilyen más dokumentumformátumba kompromisszumok nélkül, ha véglegesíthető. És persze legyen freemium változata.

A felsorolt szempontok éppen azok, ami a leggyakrabban alkalmazott módszerekből hiányzik. Előfordul, hogy még csak nem is PDF-et, hanem Word dokumentumot kell küldenem vázlatként emailen keresztül, ami dög nagy, a címzettnél máshogy jelenhet meg függően attól, hogy milyen Office-verziót használ, de legalább a dokumentumba ágyazott részeket, például képeket még pluszban is csatolni kell az emailhez, amitől persze ésszerűtlenül nagy lesz az email és ha tervezetről vagy vázlatról van szó, nyilván végig kell játszogatni mindezt újra és újra minden módosítás után. Ehelyett emailen egy linket küldeni, ami olyan doksira mutat, amihez csak a feljogosított férhet hozzá, online módon azonnal szerkeszthető, látszik, hogy ki, mikor, mit szerkesztett, írt át, túl egyszerű is lenne, nem?  A kész dokumentum átküldésétől már fél fokkal jobb a Google Docs, ami részben megvalósítja ugyan a fent felsorolt feltételeket, de a jogosultságkezelése miatt gyakorlati szempontból egyáltalán nem mondható biztonságosnak.

Miután írtam példát arra, hogy mi nem megoldás, írok néhányat, ami viszont jó választás, nem garantálom, hogy a felsorolás nem szubjektív, de ismerve vagy legalább alaposan kipróbálva 40-50 ilyen rendszert, csak-csak van rálátásom, hogy melyik milyen, a végén pedig egy univerzális trükköt is leírok, amivel az adatvesztés kockázata szinte 0-ra csökkenthető.

Microsoft Word Online

Igen, személyes kedvenc, mivel minden eszközről gyorsan elérhető, egy mezei Microsoft Accounttal használva, Onedrive-val tökéletes választás. Ugyan nem tudom, hogy ha a megosztott dokumentumnak több, írásjoggal rendelkező szerzője is van, akkor jegyzi-e a verziókövetés, hogy egy-egy módosítást ki hajtott végre, az viszont tény, hogy a dokumentum összes korábbi verziója előcibálható, mivel folyamatosan ment a háttérben, ennek megfelelően hiába szúr el valaki valamit alaposan egy dokumentumot, azonnal meg tudja nézni, hogy melyik a legutóbbi még helyes változat és vissza tudja állítani azt. Ez egyébként szinte az összes itt felsoroltra igaz. A MS Officera sajnálatosan ráragadt az a máz, hogy a nagy és gonosz redmondi cég méregdrága szoftvercsomagja, érdemes tudni, hogy a Microsoft Accounttal kínált online Office gyakorlatilag minden funkcióval rendelkezik, amire szükség lehet, ezen kívül extra kiegészítőket is lehet hozzá beépíteni, amilyen például a helyesírás ellenőrző. Megjegyzem, az Office-ra is igaz, ami a legtöbb szoftvercsomag esetében, azaz teljesen értelmetlen mindig a legújabbat választani. A windowsos asztali gépemen Office 2003-at használok, de a több, mint tíz éves verzióban nincs olyan funkció, ami egy újabban benne van ugyan, de hiányoltam volna.

Microsoft Onenote Online

Tekinthetjük a Word Online lightweight változatának, egyszerű jegyzettömbnek tűnik, amiben viszont nem klasszikus dokumentumokat hozhatunk létre, hanem noteszeket, szükség esetén azon belül alnoteszeket, amibe a bejegyzések kerülnek. Finoman skálázható, hogy egy-egy noteszt, alnoteszt vagy jegyzetet kivel osztunk meg csak olvasásra vagy szerkesztésre. A mentéssel egyáltalán nem kell foglalkozni, mivel folyamatosan menti a dokumentum aktuális állapotát a háttérben néhány másodpercenként. Külön erősség, hogy a Onenotenak nem csak az online változata ingyenes, hanem az asztali gépre telepíthető kliensprogramja is, ami akkor lehet hasznos, ha nagyon lassú netet használunk, ekkor a kliensproram határozottan gyorsabb, mintha böngészőből használnánk. Profin meg van oldva, hogy a gyakran használt funkciók vannak csak előtérben, hogy ne zavarja meg a sok beállítási lehetőség a felhasználót, viszont sajátos igény esetén szinte nincs olyan, amit ne lehetne átállítani benne.

Zoho Docs – Zoho Writer

Ha valaki egy többszerzős szakkönyv megírásához keres professzionális eszközt, tökéletes választás. Gyakorlatilag nem merülhet fel olyan igény, amit a Zoho Docs ne tudna kielégíteni. Senkit se ijesszen el a számtalan feature, elvégre más programcsomagban sem kell foglalkoznunk minden rendelkezésre álló lehetőséggel, ami el van rejtve a beállítások közt. Nem kell beletanulni, hogy hogyan érjük el a korrektúrafunkciókat, a Zoho Docs egyértelműen, eltérő színnel kijelölve tudja mutatni, hogy ki, mit, mire, mikor módosított, ezen kívül nagyon egyszerűen lehet apró buborékokban szerkesztői megjegyzéseket írni egy-egy részhez. A funkciógazdagsága ellenére a Zoho Writer használata mégis egyszerű, mint a faék, ha nem akarjuk látni a tengernyi lehetséges feature-t, egyszerűen elrejthetjük. Ami különösen tetszik benne, hogy a szerkesztői jogosultságok finomhangolhatóak, mi több, a dokumentumok tulajdonosa azt is előírhatja, hogy a dokumentumot szerkesztő felhasználók csak akkor férhetnek hozzá, ha eléggé erős, adott hosszúságú és komplexitású jelszót használnak, esetleg kötelező kétlépcsős hitelesítéssel.

A Zoho Docs a sok-sok szolgáltatásból álló Zoho Suite része, egy domainnévre azért szükség van a regisztrációhoz, egy domain regisztrálása viszont ma már nem több 5-10 percnél, ha esetleg nem lenne.
A Zoho Docs ráadásul nagyon jól kombinálható a Zoho Projects-szel, ha például egy tankönyv írásakor a fejezeteket nyilván határidőkre kell megírni, különben az életbe sem készülne el a könyv.

Evernote

A szép zöld elefántos alkalmazás a Onenotehoz hasonlóan minimalista megjelenésű, ugyancsak rendelkezik nagyon gyors asztali gépes változattal, ami automatikusan menti a változtatásokat, fontos eltérés viszont, hogy itt bizonyos lehetőségek, így a verziókövetés csak a fizetős változatban érhetők el.

Gingko

Mindegy, hogy valaki apró feljegyzést készítene, egy komplett regényt ír, aminek a sztoriját menet közben találja ki vagy doktori disszertáción dolgozik, a Gingko mindre alkalmas. Különlegessége, hogy alkalmazkodik ahhoz, ahogyan az emlékezetünk tárolja, struktúrálja az ötleteket, amiket leírunk és mindezt nagyon szemléletesen meg is jeleníti. Egy cetlihez hozzá lehet fűzni leveleket, ahhoz al-leveleket, ezek sorrendjét lehet cserélgetni és így tovább. Ha valakinek olyan az írási stílusa, hogy tervezés nélkül írja azt, amit az elméjéből éppen kipattan, szükségszerűen nem lesz olyan strukturált, mint az előre megtervezetett cikkek, viszont természetesebb és kevesebb fontos részlet marad ki véletlenül, jobban a lényegre fókuszál. [Én például blogposztot így írok, - csak éppen Gingko app nélkül - annak minden hátrányával és előnyével. ] Viszont egy komolyabb cikk esetén érdemes megcsinálni, hogy először vetjük billentyűzetre a gondolatokat külön-külön levélkében, aztán amikor már több nem jut eszünkbe a témáról, akkor a levélkéket lehet rendezgetni, az ismétlődő részeket gyorsabban ki lehet szúrni, végül pedig mindebből egy jól struktúrált, ismétlődésektől mentes publicisztika vagy akár novella jöhet ki. Ez a kezdeti tagolás azért is fontos, mert egy egybefüggő dokumentumban nehezebben vesszük észre, ha ismételjük önmagunkat vagy egyszerűen valamelyik mondat nyelvhelyességi hibát tartalmaz.

Most pedig egy kis varázslat!

ízlés dolga, hogy valaki szivesebben szerkeszt dokumentumot böngészőben, teljesen online módon vagy kliensprogramon keresztül, ahol nyilván akkor is folytatódhat a szerkesztés, ha megszakad a netkapcsolat, mert annak helyreállása után a dokumentum azóta szerkesztett verziója kerül fel a tárhelyre. Viszont sokan tapasztalhattátok, hogy ha szerkesztetek valamilyen dokumentumot, akkor rendszerint, de nem mindig abban a mappában, amelyikben a dokumentum van, amíg a dokumentum meg van nyitva, létrejön egy vagy több átmeneti, rejtett fájl, például „~$tlitől a.doc”. Ezek a fájlok abban az esetben is létrejönnek, ha esetleg az automatikus mentés teljes egészében ki van kapcsolva, ugyanis ez a szövegszerkesztő belügye. Ha bezárjuk, az átmeneti fájlokat automatikusan törli, ha pedig lefagy a szövegszerkesztő, akkor az újraindítást követően ebből a fájlból tudja előcibálni a dokumentum utolsó ismert változatát akkor is, ha a felhasználó az automatikus mentést kikapcsolta és nem taposott eléggé gyakran a mentés gombra.

Természetesen ennek is van biztonsági vonatkozása: ha például egy cég főnöke egy szabadalmaztatás előtt álló gyógyszerészeti technológia végleges leírásán dolgozik, amiben részt vett sokszáz kutató tíz éven keresztül, miközben elköltöttek félmilliárd dollárt, jó esetben van annyi esze, hogy alkalmaz valamilyen titkosítást a gépén. Viszont az ideiglenes fájlok helye nem feltétlenül a dokumentumok számára kijelölt mappa, minél be van állítva a titkosítás, lehet olyan mappa is, ami tárol mindenféle átmeneti fájlt a háttérben és törli, ha már nincs rá szükség, mert a felhasználó a szövegszerkesztőből kilépett vagy kézzel mentette a fájlt. A törlésről pedig tudjuk, hogy az operációs rendszer számára csak annyit jelent, hogy felülírhatóként jelöl meg egy területet, de maga az adattartalom fizikailag nem semmisül meg. Ennek megfelelően ha valaki a laptopot ellopja, még ha nem is fér hozzá a munkadokumentumhoz, mivel az titkosított, esetleg még jelszóval is védett, az ideiglenes fájlokat ki tudja nyerni és meg is tudja nyitni!

Hogy szemléletesebb legyen a dolog, érdemes letölteni Windowsra a Recuva ingyenes változatát majd a telepítés után futtatni egy gyors scannelést és azonnal látszódni fog, hogy hány ezer fájl van, amik vagy alkalmazások ideiglenes fájljai vagy ismerős fájlok, amikor közül többet már száz éve töröltünk a lomtárból is, de minden további nélkül visszaállítható. A háttértáron minél nagyobb a szabad hely és minél kisebb az adatmozgás, annál több visszaállítható fájl fog maradni.

Márpedig amikor egy szövegszerkesztő alkalmazás vagy kliensprogram egy átmeneti fájlt eltávolít, az az operációs rendszer számára ugyanolyan törlésnek számít, minta a felhasználó törölt volna valamit kézileg. Ezért érdemes ellenőrizni, hogy a Word, OneNote, Evernote és a többi az átmeneti fájlokat hol tárolja és beállítható, hogy egy általunk létrehozott külön könyvtár legyen az a mappa, amiben ezek az átmeneti fájlok létrejönnek. Az átmeneti fájlok mappáját pedig érdemes EFS-sel vagy más fájlrendszeri szintű titkosítással titkosítani.

Emellett beállítható, hogy maga az ideiglenes fájlok mappája egy olyan mappa almappájában  legyen, ami folyamatosan szinkronizál a Onedrive-val, MEGA-val vagy a Google Drive-val. Ahogy írtam, a jól nevelt alkalmazás automatikusan ment, az ideiglenes fájlokat pedig törli. Ezek a fájlhoszting szolgáltatások pedig természetesen nem tudják, hogy egy-egy fájl hagyományos felhasználói fájl vagy egy szövegszerkesztő által létrehozott ideiglenes fájl-e, azt folyamatosan töltik fel a felhőbe – és a lényeg – hogy amikor törli őket mondjuk a Word, amikor kilépünk belőle, a Onedrive/MEGA/Google Drive tárhelyen is kukába kerül [legalábbis az első kettőnél biztosan, a harmadikat meg nem használom, de emlékeim szerint ott is]. Mi ennek a szépsége? Azon túl, hogy a fájlhoszting szolgáltatásban a kukára kattintva egy órácskányi szövegszerkesztés után sok-sok hülye nevű fájlt figyelhetünk meg, ez pluszban biztosítja, hogy egy kiadós adatvesztés esetén mi magunk is elő tudjuk cibálni a dokumentumot, hiszen annak tartalmát tárolják ezek az ideiglenes fájlok. Mivel normális fájlhoszting szolgáltató egyébként is titkosított csatornán küldözgeti a fájlokat a felhőbe, ilyen szolgáltatás esetén nem kell különösebben tartanunk attól, hogy azt valaki közben lenyúlja, amíg a hálózaton halad, ahogy természetesen az Evernote és a Onenote kliens is titkosítva talicskázza fel a saját fájljait.

Az előbb leírt módszer szépsége, hogy a még az olyan ezer éves, verziókövetéssel nem rendelkező szövegszerkesztőknél is, mint amilyen egy nagyon régi MS Word, végülis prosztó módon, de megoldott a verziókövetés, hiszen a dokumentum korábbi változatai mind ott lesznek a felhőbeli lomtárban, ráadásul jó sok.

Lehet, hogy amit leírtam, töménynek tűnik, de azt, hogy mivel szerkesztünk, osztunk meg, hogyan oldjuk meg a verziókövetést és minimalizáljuk az adatvesztés és adatlopás kockázatát, csak egyszer kell kitalálni, majd normálisan beállítani, utána gyakorlatilag nem fordulhat elő olyan, hogy egy dokumentumot újra kell írni, mert a pendrive-ot lenyúlták, a Béla gépét ellopták, lehalt a rendszer, akármi.

Professzionális, mégis könnyen használható eszközök állnak rendelkezésre, amik ma már mindezt ingyenesen lehetővé teszik, érdemes élni a lehetőséggel és pár perc tanulással átszokni a pattintott kőkorban megszokott megoldásokról.

 Ahogy egyre nagyobb részben folytatjuk a személyes és munkához kapcsolódó kommunikációt is a neten, folyamatosan vált egyre fontosabbá, hogy minden olyan eszköz, ami ezt biztosítja egyre stabilabb és biztonságosabb legyen. Ezeknek az szolgáltatásoknak az egyike az email, ami - ahogyan írtam a korábbi posztomban - mai formájában legalább három évtizede létezik, megelőzte a web születését közel tíz évvel, a net legősibb, máig széles körben használt szolgáltatása és alighanem minden webes óriást túl fog élni, amiről ma még nem gondolnánk, hogy valaha bizony vége lesz.  
 
Kiemelt fontosságú, hogy ha emailt kapunk, ellenőrizhető legyen, hogy a feladó valóban az-e, akinek gondoljuk, ezt pedig sokszor ugyan azokra a technikákra támaszkodva lehet megtenni, amit spamvédelem céljából kitaláltak. Egy durván meghamisított levél példáján mutatom be, hogy mikor mit érdemes nézni, az emailek hosszú fejléce minden webes levelezőrendszerben megjeleníthető, a legelterjedtebb Gmail esetén például a levél megnyitását követően a legördülő menüben a Show original pontra kattintva. 

 Amikor valaki egy nevet és egy hozzá tartozó email címet lát a feladó mezőben, teljesen természetesnek veszi, hogy a levelet az írta, akinek a neve és címe olvasható, nemde? Óriási tévedés! Az, hogy a feladó neve és a cím mezőben mi álljon, csupán egy adalék információ, amit a feladó szervere az email fejlécéhez hozzáfűz, viszont semmiféle megkötés nincs azzal kapcsolatban, hogy ott mi szerepelhet, mi több, még az sem megkötés, hogy ki legyen töltve. Viszont abban az esetben, ha valaki megmókolja a levelezőrendszert a levélküldés idejére olyan módon, hogy az valamilyen tetszőleges címet csapjon a levélhez, a levél elmegy ugyan, a címzettnél akár a spam mappába megy, akár sem, a levelezőrendszerek a címzettnél jó esetben figyelmeztetnek azzal kapcsolatban, hogy a levél valószínűleg hamisívány. Viszont, ahogy a frissen előállított példában látszik, simán lehet, hogy nem, annak ellenére, hogy minden arra utal, hogy a levél hamisítvány, mégsem jelzett a Gmail emiatt. Hamisított levélre utaló figyelmeztetést eredményezhet más is legitim levelek esetében, viszont érdemes tudni, hogy hogyan tudható meg esetleg több a valódi feladó kilétéről. 
 
Nosza, lássuk azt az előbb emlegetett hosszú fejlécet! 
 
Delivered-To: bardoczi@gmail.com 
Received: by 10.27.186.198 with SMTP id k189csp415282wlf; 
        Fri, 8 Jan 2016 03:48:06 -0800 (PST) 
X-Received: by 10.140.101.201 with SMTP id u67mr91933194qge.33.1452253686478; 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Return-Path: <president@whitehouse.gov> 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
        by mx.google.com with ESMTPS id r9si92146028qhb.7.2016.01.08.03.48.06 
        for <bardoczi@gmail.com> 
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); 
        Fri, 08 Jan 2016 03:48:06 -0800 (PST) 
Received-SPF: softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) client-ip=104.193.143.56; 
Authentication-Results: mx.google.com; 
       spf=softfail (google.com: domain of transitioning president@whitehouse.gov does not designate 104.193.143.56 as permitted sender) smtp.mailfrom=president@whitehouse.gov 
Received: from localhost ([::1]:63179 helo=ecbiz178.inmotionhosting.com) 
    by ecbiz178.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) 
    (Exim 4.85) 
    (envelope-from <president@whitehouse.gov>) 
    id 1aHVWX-000DKS-T9 
    for bardoczi@gmail.com; Fri, 08 Jan 2016 06:48:06 -0500 
Received: from 179.43.161.147 ([179.43.161.147]) by 
 secure178.inmotionhosting.com (Horde Framework) with HTTP; Fri, 08 Jan 2016 
 11:48:05 +0000 
Date: Fri, 08 Jan 2016 11:48:05 +0000 
Message-ID: <20160108114805.Horde.zOWNX3cXXgeNf-MxqaUvuw5@secure178.inmotionhosting.com> 
From: President of US <president@whitehouse.gov> 
To: bardoczi@gmail.com 
Subject: =?utf-8?b?aGFkw7x6ZW5ldA==?= - fake =?utf-8?b?bGV2w6ls?= 
Reply-to: akos@null.net 
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) 
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes 
MIME-Version: 1.0 
Content-Disposition: inline 
Content-Transfer-Encoding: 8bit 
X-OutGoing-Spam-Status: No, score=3.6 
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report 
X-AntiAbuse: Primary Hostname - ecbiz178.inmotionhosting.com 
X-AntiAbuse: Original Domain - gmail.com 
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] 
X-AntiAbuse: Sender Address Domain - whitehouse.gov 
X-Get-Message-Sender-Via: ecbiz178.inmotionhosting.com: authenticated_id: akos@genetics.bardoczi.net 
 
A valódi küldő felhasználó azonosítása és a feladó mező összevetése az első lépés.  
 
A hosszú fejléc sorai közt az X-szel kezdődők nem kötelezők a levelezőrendszerek számára. A levelezőrendszereknek nem kötelező hozzáfűzniük, hogy egy levelet pontosan milyen felhasználó vagy alkalmazás feladói felhatalmazásával küldenek, viszont ha nem totálisan hülyén van konfigurálva a levelezőrendszer, akkor tartalmaz ilyet, ez jelen esetben az "authenticated_id: " sor, amivel gyakorlatilag semmi sem stimmel. A sorban lévő akos@genetics.bardoczi.net csak annyit mond, hogy amikor a levelezőrendszer átvette kézbesítésre a levelet, akkor ezzel a felhasználói névvel lett feljogosítva a levélküldésre. Ha semmilyen azonosítás nem feltétele egy levél kiküldésének, ún. open relay szerverről beszélünk, azaz olyan levelezőszerverről, amin keresztül bárki bármit küldhet bármiféle azonosítás nélkül. Mivel valamikor rég ezeket előszeretettel használták a spammerek, open relay-t már nagyon keveset találunk, hiszen ha olyan helyről érkezik email, azzal valami teljesen biztos, hogy nem stimmel. Ugyan vannak a neten olyan oldalak, ahol egyszerűen csak meg kell adni, hogy mi kerüljön a feladó, a tárgy és az üzenet mezőbe, hova menjen az email, az ilyen levelek jobb helyeken közel biztos, hogy spamben landolnak, másrészt általában még az ilyen kamu emailek sem open relayen keresztül mennek, hiszen a hamisító szolgáltatás van feltüntetve küldésre feljogosított felhasználóként, ami persze csak a hosszú fejlécből derül ki. Viszont vegyük észre, hogy legalább van lehetőség azonnal kideríteni, ellentétben például a Facebook-üzenettel, amivel a továbbiakban nem fogom hasonlítgatni az emailt.  
 
A bűvös boríték és "vissza a feladónak", azaz envelope és return-path 
 
Ha jobban megfigyeljük a levelet, figyelmesek lehetünk az egyik Received sorban található "envelope-from <president@whitehouse.gov>" részre. Az envelope, azaz boríték azonosításához a levelezőrendszerek sokszor külön sort hoznak létre, akkor biztosan, ha az nem egyezik a valódi emailcímmel, ami felhasználói név is egyben. Még a Return-path sorban is a hamis email cím szerepel, ami azt a címet tartalmazza, ahova a címzett szerverének mailer daemonjától várja a visszaküldést akkor, ha a kézbesítés sikertelen valami miatt, azaz ide pattan vissza a feladóhoz a levél. Egy szó, mint száz, ebben az esetben (sem) szerepelt valami fényesen a legelterjedtebb kommersz levelezőrendszer a kamu levél kiszűrérében. 
 
A postás és a postahivatal  
 
Persze az azonosított feladó cím lehet, hogy még mindig nem mond semmit, az első Received sorban lévő szerver hosztneve és IP-címe már egyértelműen azonosítja, hogy mi is vette át a levelet küldés céljából elsőként:  
 
Received: from ecbiz178.inmotionhosting.com (ecbiz178.inmotionhosting.com. [104.193.143.56]) 
 
Márpedig ha ennek utánanézünk például az ARIN adatbázisában, abból kiderül, hogy a levél egy mezei hosztingszolgáltatótól jött, ráadásul azon belül is egy olyan szerverről, ahova a filléres hosztingot igénylő ügyfelek oldalait teszik, mint amilyen az én életrajzi oldalam. Ennek ténye egyre valószínűtlenebbé teszi, hogy a levél valóban a Fehérházból jött volna.  
 
Amikor az email küldéshez szerver sem kell  
 
Megjegyzem, elvben az is megoldható, hogy valaki az otthoni gépére telepítsen olyan szolgáltatást, amin keresztül tud levelek küldözgetni úgy, hogy maga a levelezőszerver is az ő otthoni gépe. Normál esetben egy levelezőszerver IP-címéhez tartozik egy hosztnév, ebben az esetben a reverse hostname-re gondolok, azaz ha nem tudnánk, hogy a ecbiz178.inmotionhosting.com hosztnévhez a 104.193.143.56 cím tartozik, a cím alapján meg lehet nézni a hosztnevet, már ha van.   
 
Egy egyszerű internetszolgáltatással rendelkező gépnek viszont nincs feltétlenül szüksége arra, hogy ahhoz hosztnév legyen hozzárendelve, abban az esetben pedig, ha mégis van hozzárendelve, akkor arról általában süt, hogy otthoni felhasználók gépeinek, végfelhasználóknak kiosztott hosznévről van szó. Egy UPC-s magánelőfizető IP reverzje aaa.bbb.ccc.ddd cím esetén catv-aaa-bbb-ccc-ddd.catv.broadband.hu lesz, azaz látszik ugyan, de ebből azonnal kiderül az is, hogy nem szerverről, hanem valakinek az otthoni gépéről van szó, a címre egyszerűen elég rákeresni az európai és közel-keleti IP-ket nyilvántartó RIPE-adatbázisában, ha nem lenne elég egyértelmű. Hasonlóan például egy Vodafone-os magánelőfizető címe hiába reverselhető, a RIPE lekérdezés alapján egyértelmű, hogy magánelőfizetőről van szó és nem pedig levelezőszerverről:  
 
 Még egy kicsit a hamisított feladói címről  
 
Adott címről érkező levél esetén természetesnek vesszük, hogy arra simán válaszolva a címzettnél meg is érkezik valami. Amikor emailt küldünk valakinek, a kézbesítéshez többek közt a domain név szolgáltatáson keresztül le kell kérdezni a hosztnévhez tartozó ún. MX-rekordokat, ami azt dönti el, hogy a beérkező emaileket mely gépek kezeljék, azaz kik töltik be a postahivatalok szerepét, ha a domain-nevet tekintjük a címzett városának. Ez a freemail.hu esetén például fmx.freemail.hu ugyan a netes szolgáltatások szabványosításáért dolgozó IETF azt javasolja, hogy levelet fogadó domainhez legalább kettő MX-rekord, azaz „postahivatal” tartozzon arra az esetre, ha az első valami miatt nem érhető el vagy túlterhelt, de ne is legyen belőle 10-nél több. Persze könnyen lehet, hogy ha csak egy MX-rekord van, akkor az egy terheléselosztó vagy tűzfal, mögötte sok-sok postással. Mégis gyakoribb megvalósítás, hogy MX-rekordból több van, a secure.bardoczi.net domain esetén például 14, földrajzilag gondosan távol egymástól, épphogy a Holdon nincs.   
  
Viszont ha az email címben szereplő domainhez nem tartozik MX-rekord, akkor gyakorlatilag biztos, hogy kamu címről van szó, hiszen MX-rekord nélkül az adott domain nem tud emailt fogadni, az pedig életszerűtlen hogy úgy működjön egy domain név, amiről csak küldeni tud, de fogadni már nem. A genetics.bardoczi.net jelen esetben ilyen:  

http://mxtoolbox.com/SuperTool.aspx?action=mx%3agenetics.bardoczi.net&run=toolpage  

Mi lehet a célja egy ilyen emailes scamnek?  
 
Felmerül a kérdés, hogy a példában hozott scam emailnek mi lehet a célja, miért kér a feladó bankkártyaadatokat, ha ezek szerint a president@whitehouse.gov címre érkezett levelet úgysem kapná meg, mivel nem is ő küldte? És egyáltalán: mindig érdemes a levél tartalma alapján felállítani néhány forgatókönyvet azzal kapcsolatban, hogy valaki kamu címmel, kamu személyazonossággal vajon miért írja pont azt, amit? Ebben a levélben ugye arról van szó, hogy ha a címzett nem küldi a bankkártyaadatait, itt bizony vér fog folyni. Mivel a Gmail rövid fejlécéből nem derül ki semmi szokatlan, a laikus felhasználó gondolhatná, hogy ha a válasz gombra kattint, a levél a whitehouse.gov-os címre küldi a levelet, ha viszont kamu, úgyis visszapattanna, nemde? Igen ám, viszont abban az esetben, ha a válaszcím, azaz az a cím, amire a feladó a választ várja, eltér a feladó címétől, ilyenkor a levelezőrendszernek kötelező elhelyeznie egy Reply-to sort, amiben pedig az akos@null.net cím van, aminek aligha van bármi köze is a Fehérházhoz. Viszont amikor az egység sugarú felhasználó a válasz gombra kattint, egyáltalán nem veszi észre, hogy a címzett mezőben már más cím szerepel, mint amiről a levél érkezett, amit épp megválaszol és erre a levelezőprogramok nem is hívják fel a figyelmet!  
 
Jelen példa persze blőd, de gondoljunk bele, hogy a feladó mezőben simán szerepelhetne egy bank címe is, a levélben a bankra jellemző arculati elemekkel és persze hihetőbb szöveggel, a válaszcím pedig lehet bármilyen ingyenes mailszolgáltatónál létrehozott, esetleg totálisan visszakövethetetlen emailcím, amire a csaló a kért adatokat megkapja, ha az áldozat válaszol is rá.   
 
A spamekkel és scamekkel vívott automatizált küzdelem  
 
Felmerülhet a kérdés, hogy hogyan jelenthet csak a spam önmagában sok-sok százmillió dolláros össz-veszteséget évről évre, ha olyan levelekről van szó, amiket a felhasználó úgysem olvas el? Úgy, hogy a spamek küldése, fogadása mind használja az IT erőforrásokat, legyen szó akár az adatátvitelről, akár arról, hogy ezeket a leveleket a levelezőszervereknek fel kell dolgozniuk, ami ugye processzoridőben mérhető, és persze valameddig tárolni is kell őket, aminek szintén forintosítható-dollárosítható ára van. Ahogyan annak is, ha az alkalmazott megnyit egy spamet, ha az olvasására csak negyed percet szán, az is a munkaidejéből megy el. Mindezek bagatell apróságoknak tűnnek, de ha nagyban gondolkozunk, ha már felhasználók számilliói érintettek, érthető, hogy miért kerül nagyon sokba a spam, még ha jól is van szűrve, nem is beszélve arról az esetről, amikor egy fontos levél falspozitívként kerül spambe és valaki nem értesül időben valamiről, ami egyébként fontos lenne. A scam, azaz a megtévesztő levél más műfaj és máshogy is okoz költségeket és kellemetlenségeket, például ha a felhasználó olyan linkre kattint, amivel valamivel alaposan lefertőzi a gépét, amit az antivírus termék nem szúr ki.  
 
Ami a spamben és a scamben közös, hogy nyilván minél jobban hasonlítaniuk kell a legitim levelekhez, hogy megtévesszék a spam- és scamszűrő rendszereket és eljuthassanak a felhasználókig. Így a versenyfutás a spammerek és a levelek biztonságáért felelős fejlesztők és kutatók közt folyamatos. Alapvetően a legitim és fölösleges-kártékony levelek szűrése a tartalom és a fejléc automatizált elemzésével történik. A tartalom alapú elemzéssel itt egészen röviden foglalkozom. Igencsak kifinomult gépi tanuláson alapuló mechanizmusok dolgoznak a háttérben, amikor nagy mintán tanulják a szerverek, sokszor közösen, hogy mik a spamek és a legitim levelek jellemzői, ez alapján következtetnek.  
 
A gépi tanulás lényegéről korábban már itt írtam annak kapcsán, hogy hogyan idomítottak be egy gépet arra, hogy megkülönböztesse az előnyös és az előnytelen szelfiket. A kifinomult tanulóalgoritmusok helyett vegyük a legegyszerűbb hipotetikus spamszűrőt: ha tudjuk, hogy egy 1000 levélből álló mintában abból a 200-ból, ami tartalmazza a Viagra kifejezést pontosan 199 spam, akkor a jövőre nézve biztosak lehetünk benne, hogy ha jön egy levél, aminek a szövegezésében a Viagra szerepel, jó eséllyel ugyancsak spam lesz. Ez az ún. Bayes-valószínűségen alapuló szűrés.  
 
Vissza a fejlécekhez  
 
A levélszemét szűrésének tartalmi elemzést megelőző lépése viszont a – sokkal kisebb számításigényű – fejlécelemzés, ráadásul ha a fejléccel túl sokminden nem stimmel, a levelet esetleg a szűrő már nem is vizsgálja tartalmi szempontból. A header elemzésekor többek közt a levelezőrendszer olyan sajátosságok után kutat, amikről írtam a poszt első felében, azaz amik végképp nem jellemzők egy normális emailre. Másrészt idővel bevezettek olyan technológiákat, amik a fejlécben helyeznek el extra, az emailt hitelesítő sorokat, azaz olyan sorokat, amiket pillanatok alatt ki tud elemezni első körben a fogadó szerver. Ezek ugyan messze nem tökéletesek, de jobbak, mintha csak tartalom alapú elemzésre és az alapvető ellentmondások elemzésére támaszkodhatna a spamszűrő.  
 
A Sender Policy Framework, avagy SPF  
 
A legősibb és legegyszerűbb megoldást az SPF jelentette. Szinte minden levél hosszú fejlécében találunk SPF-re vonatkozó sort, ami mutatja, hogy a domainhez beállított SPF-szabályokkal összevetve a levelet milyennek értékelte a szerver. Az SPF-szabályokat pedig a doménnév szolgáltatásból tudja lekérdezni. A kiértékelés eredménye lehet semleges, legitim vagy éppenséggel bukó, de ezzel a levél sorsa természetesen nem dől el végleg, hanem csak hozzáad vagy kivon abból a pontszámból, ami fölött a fogadó szerver egy levelet spamnek talál.  
 
Példaként, ha az SPF-szabály IP-cím alapján van meghatározva a domainhez tartozó domain név szerverben, az egy ilyesmi bejegyzés lehet a domainhez tartozó rekordok közt:  
 
v=spf1 a:kuldoszerver.example.com –all  
 
Ez annyit jelent, hogy a fogadó fél megnézi a küldést végző hosztnév IP-címét vagy hosztnevét és ha az egyezik azzal az IP-címmel, ami a kuldoszerver.example.com domainhez tartozik, akkor az a levél legitim, minden más esetben viszont valószínűleg spam, ezért el kell dobni, amit a -all paraméter határoz meg.  
 
Az SPF szűrési logikája alapulhat még más egyéb tényezőkön is, a fenti példát azért választottam, mert a legegyszerűbb, de van még pár beállítási lehetőség bőven.  
 
Fontos, hogy az SPF nem élet és halál ura, azaz ha például egy adott domainről érkezik hamisított feladóval egy levél, amit biztosan nem a domainhez tartozó levelezőszerveren keresztül küldtek, akkor az az SPF szerint spam ugyan, viszont a kifinomultan konfigurált spamszűrő csak egy valószínűségi értéket rendel hozzá, hogy ennek alapján a levél elbuktott, legitim vagy semleges. Hosszú lenne kifejteni, de az SPF működésmódjából adódóan egyrészt még ez is megkerülhető a spammerek számára, másrészt elvben előfordulhat, hogy egy teljesen legitim levél repül spambe. Másrészt ahogy írtam, az SPF megléte a névszerveren  nem is kötelező.  
 
Példaként ha valaki nem webes felületről, hanem kliensprogramból használja a postafiókját, viszont Indamailt vagy Freemailt használ, amivel a levelek letölthetők ugyan, viszont küldeni levelezőprogramon keresztül nem lehet, a felhasználó kénytelen lesz más szervert használni a küldéshez, például a netszolgáltatója levélküldőjét, azaz SMTP-szerverét. Könnyen belátható, hogy az előző SPF-logika alapján a levél minimum spamgyanusnak lesz nyilvánítva a fejléce alapján, ilyen szempontból kész szerencse, hogy eléggé kevesen használnak levelezőprogramot böngésző helyett a levelezéshez, viszont akik igen, ezt általában tudják is. Azt hinnénk, hogy a túl szigorú SPF beállítás, azaz amikor a szűrést végző szerver nem csak lepontozza a levél hitelességét, hanem vakon az SPF alapján jár el és el is dobja azt, nem túl gyakori beállítás. Sajnos olyan cégek is gyakran rosszul konfigurálják a szűrést küldésre és fogadásra vonatkozóan, amikről nem hinnénk.    
 
DomainKeys, DKIM és az Identified Internet Mail  
 
Ezek a megoldások elvben nem voltak jobbak vagy rosszabbak, mint az SPF, hanem teljesen mások, gyakorlatilag viszont jóval korszerűbbek, számos olyan sajátossággal rendelkeztek, amik mégis nagyban megnehezítették egy-egy email meghamisítását.  
 
Mindháromnak az alapját az jelenti, hogy a domaint működtető névszerveren be van állítva egy publikus kulcs, amit a küldő szerver aláír, majd a fogadó fél szervere lekérdezve ezt a publikus kulcsot ugyancsak a névszerverről, a feladó legitimitásának azonosításán túl azt is ellenőrzik, hogy az emailt átvitel közben esetleg nem hamisították-e meg, ami sokkal gyakoribb és egyszerűbb, mint ahogy azt az Olvasó gondolná.  
 
Ugyanakkor több szempontból sokkal nagyobb rugalmasságot biztosít, mint az SPF, hogy mást ne mondjak, elvben az SPF egy sima szöveges rekord ugyan a névszerveren, mi több, lehet el kilométeres is, gyakorlatilag a fogadó fél gyakran nem értelmezi a szabályt, ha 255 karakternél hosszabb.  
 
A Yahoo által kitalált DomainKeys és a Cisco-tól származó IIM összegyúrásából született DKIM esetén viszont ugyanazzal az email-címmel való üzenet küldéséhez használhatjuk teljesen eltérő szolgáltatók küldő szervereit is, a küldő szerver egyszerűen csak hozzácsapja a nyilvános kulccsal és persze az általa használt titkosító algoritmussal kiszámított ellenőrzőösszeget, amit a fogadó fél majd ellenőriz. Ugyan a DomainKeys-t, azaz DK-t, amit gyakran kevernek a DKIM-mel, elvben felváltotta az utóbbi, gyakorlatilag viszont nagyon sok szerver előnyben részesíti, ha a levél a régivágású módszerrel is alá van írva. Annyira, hogy a példánál maradva a Gmail máig csak akkor fogad el teljesen hitelesnek egy levelet, ha helyes DomainKeys értéket is talál benne.  
Az alábbi ábrát az appmaildev.com-ról vettem át:  
 

Hogy a saját leveleink tartalmaznak-e SPF, DK és DKIM értékeket, valamint azok helyesek-e a http://www.appmaildev.com/en/dkim/ -en ellenőrizhetjük, ahol egy email-címre küldött levelet követően a szolgáltatás egy részletes elemzést fog visszaküldeni.  
 
Hasonló, kevésbé részletes, de áttekinthetőbb eredményt ad, ha  a http://dkimvalidator.com oldalon megjelenő email címre küldünk emailt, majd néhány másodperc múlva megnézzük az eredményt.  
 
Esetleg marginálisnak tűnik foglalkozni ilyen részletekkel, egyszer mindenkinek érdemes eljátszania vele azért is, mert abban az esetben, ha valaki egy beígért emailt nem kap meg, annak senki sem örül főleg akkor nem, ha fontos emailről lett volna szó.  
Az emailek itt ismertetett hitelesítése protokoll-szinten működik, még mindig összesen csak annyit bizonyít, hogy egy-egy adott levelet a feladó postafiókjából küldtek, azt viszont nem, hogy valóban a postafiók tulajdonosa küldte, nem pedig valaki, aki odament a lezáratlan gépéhez vicceskedni ebédidőben.  
 
Alkalmazásréteg szintjén a levelek hitelesítése a korábban tárgyaltaktól teljesen függetlenül a digitális aláírással oldható meg, aminek de facto standardja a PGP, aminek az alapjairől korábban írtam itt  a finomhangolásáról pedig ebben a posztban.  
 

Igaz, nemrég ígértem, hogy bemutatom, hogyan azonosítható egy webes felületről elküldött Gmail-es levél földrajzi helye, annak ellenére, hogy a Gmail-en keresztül küldött levél nem tartalmazza a kliens IP-címét - ellentétben a Google Apps-en keresztül küldött levelekkel, amik igen! -  mindez esélytelen lenne ésszerű terjedelemben úgy, hogy közérthető is legyen - viszont kommentben tippelni lehet!  
Képek: filterforge.com, pophangover.com, themetapicture.com 

Ahány munkahely annyi szokás, viszont alighanem mindenki belefutott már abba a kérdésbe, hogy vajon mennyire jó ötlet a munkahelyi gépet magáncélra használni, mennyit tudhat róla az IT-s, a főnök, esetleg olyan is, aki jóval pletykásabb az elviselhetőnél.

Vannak munkahelyek, ahol az alkalmazott azonnal aláír egy nyilatkozatot azzal kapcsolatban, hogy a munkahelyi IT infrastruktúrát csak a munkájához szükséges célokra és módon fogja használni, ha pedig ez a policy változik, arról a munkahelynek őt is köteles értesítenie. Ez jellemzően tartalmazza azt, hogy a munkahelyi levelezés nem használható másra a rendeltetésén kívül és ezt a munkahely ellenőrizheti, mondjuk szúrópróbaszerűen és ez így helyes. Ami viszont már sokkal kacifántosabban, esetleg kevésbé érthetően van megfogalmazva, hogy a munkahely milyen mélységig láthat bele az alkalmazott netezésébe, ami a privát kommunikációját is érintheti. Főleg akkor, ha a zavarosan megfogalmazott szabályzat kiterjedhet a BYOD-eszközökre is, azaz azokra a kütyükre, amiket az alkalmazott saját maga visz be és a céges hálózatot használják.

Amivel alighanem mindenki egyetért, hogy a munkahelyére alapvetően dolgozni jár az alkalmazott, tehát mindenki joggal várhatja el, hogy ne csessze el az időt olyannal, aminek semmi köze nincs a munkájához. Ugyanakkor nagyon gyorsan kiderült az is, hogy azokon a helyeken, ahol letiltották az egyértelműen magán célra szánt, közkeletű alkalmazások használatát, mint a Twitter, a Gmail vagy a Facebook, az alkalmazottak feszélyezettebben érezték magukat, ennek megfelelően a produktivitásuk is csökkent. Röviden: az olyan típusú szolgáltatások tiltásának bevezetése, amik mindennapi kommunikációnk részévé váltak és megszoktuk, hogy elérhetőek, amikor kell, értelemszerűen csak feszültséghez vezethet. Ugyanakkor természetesen senkinek sem jó, ha az alkalmazott elcsetelgeti a munkaidő felét.

Komolyan nem tudnám megmondani, hogy melyik a legidiótább céges korlátozás, amiről olvastam vagy hallottam, de alapvetően kerülendő minden olyan módszer, ami az alkalmazottban olyan benyomást kelt, mintha a főnöke a háta mögött egész nap azt figyelné, hogy hogyan dolgozik. Természetesen kivételek vannak, kritikus feladatokat ellátó szervezeteknél nyilván megengedhetetlen lenne biztonsági szempontból, hogy onnan az alkalmazottak szabadon netezgessenek, így esetleg lefertőzzenek véletlenül egy olyan hálózatot, ami egy SCADA-rendszerhez vagy minősített adatokat tartalmazó rendszerhez kapcsolódnak valamilyen módon. Ahogy az is ismert, hogy több hadsereg nagyon helyesen megtiltotta az állománya tagjainak, hogy egyáltalán a közösségi webet használják.

Ami általánosságban elmondható, hogy az alkalmazottak alapvetően tájékozatlanok, aminek eredményeként veszélyeztetik egyrészt a céges adatok séthetetlenségét, másrészt a saját magánszférájukat is.

2010-ben hatalmas botrányt kavart a Firesheep, ami lényegében egy olyan böngésző-kiegészítő volt, ami lehetővé tette, hogy a géppel egy hálózaton lévő több gép titkosítatlan adatforgalma már-már kínos egyszerűséggel teljes egészében lehallgatható legyen. Azaz bárki, elemi informatikai előismeretekkel láthatta és jókat derülhetett rajta, hogy tőle nem messze egy kollégája miket olvas éppen a neten. Nem az az érdekes az egészben, hogy megjelent egy böngészőbővítmény, ami lehetővé tett, hogy egy mezei felhasználó úgy láthassa a másik tevékenységét, ahogyan az a zsékategóriás kémfilmekben ábrázolni szokták. Ugyanis ennek a lehetősége már ezer éve adott volt, az olyan jól ismert alkalmazások, mint mondjuk a Wireshark ugyanerre képes volt már a Firesheep előtt 10 évvel korábban is, csak éppenséggel azzal a különbséggel, hogy a Wireshark által sniffelt adatforgalom nem úgy jelent meg, mint valami kémfilmben, hanem az adatcsomagokat szépen összerakva pici hozzáértéssel simán olvasható volt a titkosítatlan forgalom, ami származhatott vezeték nélküli hálózatból és persze vezetékes hálózatból, azaz például a munkahely helyi hálózatára csatlakozva egyaránt.

Tehát igaz, hogy a probléma ismert volt már száz éve, mégis egy, végülis teljesen átlagos, mindenki számára használható böngészőbővítményre volt szükség ahhoz, hogy a világ legnagyobb szolgáltatói arra kényszerüljenek, hogy az alapértelmezett beállítás az legyen, hogy a felhasználó böngészője és a szerver közti adatforgalmat titkosítsák. Ez a gyakorlatban nem csak abból látható, hogy a böngésző címsorában a cím https-sel kezdődik, hanem az is, hogy az elején látható egy - jó esetben zöld színű, nem törött - lakat ikonja, amire rákattintva láthatjuk, hogy a kommunikáció egészen pontosan milyen titkosítás mellett történik, és egy ún. certifikátum megfelelően igazolja-e, hogy a webhely, amire kapcsolódunk, valóban az a webhely-e, aminek a címét a címsorban látjuk.

De hát ha a címsorban az áll, hogy www.bankom.tld, akkor az csak a bankom webhelye lehet, nem? Nem. Amikor a böngészőbe beírjuk a címet, a kérést az oprendszeren keresztül átadja a DNS-szervernek, ami alapértelmezés szerint mindenkinek a saját internetszolgáltatójának azon két szervere, amelyik elvégzi a névfeloldást, azaz megkeresi vagy megkeresteti a webcímhez tartozó IP-címet, ez visszakerül a böngészőhöz a kommunikáció innentől a felhasználó címe és böngészője, valamint a DNS-től megtudott www.bankom.tld oldal IP-címe közt fog folytatódni végig. /*egyszerűsítve*/

Kivéve, amikor nem!

Ugyanis lévén, hogy semmi sem garantálja azt, hogy a névfeloldásra irányuló kérésbe senki sem fog belepiszkálni a felhasználó és a szolgáltató DNS szerveri közt ún. közbeékelődéses támadással. 

Másrészt a szolgáltatók DNS szerverei ha mondjuk az elmúlt néhány órában már több milliószor feloldottak egy bizonyos címet, nem fogják ismét megkeresni azt a net dzsungelében, hanem a gyorsítótárból, "emlékezetből" veszik elő azt, a legnagyobb sérülékenységet pedig pont ez jelenti. 2008-ban éppen egy névfeloldással kapcsolatos sebezhetőség sokkolta a világot.

Tételezzük fel, hogy a támadók sikeresen beléptek a szolgáltató DNS-szerverére  és a nemrég lekért, www.bankom.tld hosztnévhez tartozó IP-címet aaa.bbb.ccc.ddd-ről átírták xxx.yyy.ppp.qqq címre, ez utóbbi pedig egy, a Karibi-térségben vagy hasonló remek klímájú országban elhelyezett szervert jelöl, amin olyan webhely fut, ami megtévesztésig hasonlít a www.bankom.tld bejelentkezőoldalára. Az ügyfél ekkor beírja a felhasználói nevét és jelszavát, amit a támadók naplóznak. A belépési adatok megadása után a felhasználó hibaüzenetet kap, miszerint rosszul adta meg a belépési adatait, majd átirányítják a valódi webhelyre, ahol már szabályosan be tud lépni, viszont nem veszi észre, hogy a bejelentkezéshez szükséges azonosítókat a támadók ellopták.

Ez ugyan egy erősen egyszerűsített példa volt a DNS működésével és annak eltéríthetőségével kapcsolatban, hiszen nincs olyan hülye bank, ami ne használna az éles felületen titkosított kommunikációt, a szerver és a kliens azonosítását, a belépés vagy egy-egy konkrét banki művelet pedig plusz egy jóváhagyást kérnek az ügyfelektől, ami mondjuk egy SMS-ben érkező számsor megadása. Viszont tartsuk észben, hogy számos levelezőrendszer van mind a mai napig, aminek a webes felülete nem alkalmaz titkosított kommunikációt, ilyen esetben ha a DNS-t célzottan eltérítik, olyan, mintha a felhasználó teljes egészében odaadta volna a postafiókja használati jogát a támadónak.

A DNS eltérítés gyakoribb, egyszerűbb, na meg sokkal kevésbé feltűnő módja, ha nem a szolgáltató DNS kiszolgálóját piszkálják meg, hanem a felhasználó gépét kihasználva azt, hogy a kliens szintén gyorsítótárazza a korábban feloldott neveket. Ha például valaki folyamatosan a Gmail-en lóg, nem fogja a böngésző minden alkalommal arra utasítani az operációs rendszert, hogy kérdeztesse le a Gmail.com-hoz tartozó IP-címet, amikor megszólítja az oldalt, hanem azt a lekéréseket cachelő helyről vagy egy,  állandó hosztnév-IP-párosokat tartalmazó, de megmókolt fájlból húzza elő, ez a másik módja a DNS hijackingnek.

Miután tisztáztam, hogy a névfeloldás jelentősége mekkora, nem csoda, hogy gyakorlatilag minden kicsit is normális operációs rendszer és személyi tűzfal úgy kezeli a hosztnév-IP-cím párosokat tartalmazó fájlba való beavatkozási kísérleteket, mintha a támadó páncéltörvővel próbálna bejönni az ajtón. Könnyebb megérteni, ha belenézünk ezekbe a fájlokba.

OSX esetén a fájlt /private/etc/hosts helyen találjuk, a legtöbb linux disztróban az /etc/hosts alatt, ha csak kimondottan át nem helyezték, míg Windows esetén a rendszergyökér\Windows\System32\drivers\etc\hosts.txt fájlban. Ez ugyan csak az állandó hozzárendeléseket tartalmazza, így nem valami izgalmas, viszont kis trükkel előcsalható, hogy az operációs rendszer az adott pillanatban miket gyorsítótárazott, itt jelen esetben biztosan meg fogjuk találni mondjuk azt, hogy a reblog.hu-hoz  a 84.2.32.100 vagy 84.2.32.101 cím, esetleg egy ún. kanonikus név tartozik. Nosza! A lista megjelenítéséhez viszont ismét lehet, hogy adminisztrátori jogosultságokra lesz szükség. A Windowsban egyszerűen el kell indítani egy parancssort adminisztrátori jogosultságokkal, majd ott kiadni az

 ipconfig /displaydns | more

parancsot, majd lehet is böngészni benne.  

Nem kell pánikba esni, ha a vártnál sokkal több hosztnevet látunk, hiszen nem csak a webes böngészéshez kapcsolódó címek láthatók it. Ha gyakran frissít a víruskeresőnk, fut közben a Skype, meg még  ki tudja mi, minden alkalmazás és szolgáltatás, ami használja a hálózatot kapcsolódik pár jóhelyre. Tovább bonyolít a helyzeten, hogy a terheléselosztás miatt egy hosztnévhez tartozhat több IP-cím is, egy IP-címhez több hosztnév, de még egy adott webhely is a tartalmainak egy részét teljesen más hosztnévről cibálja be, így például a Facebookra töltött képek esetén a scontent.xx.fbcdn.net helyről, aminek további IP-címei vannak.

Az olvasó esetleg korábban is tudott róla, hogy mi is a névfeloldás, mostanra világosabb lehet, hogy hogyan is működik, ebből adódóan mekkora kockázata annak, ha ebbe valamilyen módon beleberhelnek, a harceddzettebb bitbúvároktól elnézését kérek az egyszerűsítésekért.

A DNS-eltérítés kockázatát persze már az internet hajnalán felismerték, ezért ki kellett találni egy olyan megoldást, ami azonnal beavatkozik vagy jelez, ha erre utaló jelet talál. És persze egy pillanatig se felejtsük el, hogy ennek a megoldásnak teljesen függetlennek kellett lennie az átvivő közegtől, ideértve a csatorna köztes szakaszait is. Azaz függetlennek kell lennie attól, hogy a netező LAN-kábelen keresztül csatlakozik, titkosítatlan wifin keresztül, az adatcsomagok egy ideig telefonkábelen keresztül haladnak át, mire célbaérnek keresztülmennek 8-10 szerveren, útválasztón, amikről azt sem tudni, hogy kié és így tovább. Azaz feltétel volt a tervezésnél, hogy legyen független a megoldás a fizikai, adatkapcsolati, stb. rétegektől, így került a megoldást jelentő SSL és a vele gyakorlatilag azonos TLS [Transport Layer Security] és ami kapcsolódik hozzá, megjelenítési rétegbe.

Hogy szemléletes legyek, tételezzük fel, hogy egy papírcetlin szeretnék üzenni valamit a kollégámnak és olyan valakit bíznék meg azzal, hogy a papírcetlit vigye el neki, akiről tudom, hogy biztos, hogy úgyis elolvassa, másrészt még pletykás is, a papírcetlire az üzenetet mondjuk arab avagy japán nyelven írom, amit a címzett megért ugyan, de aki átadja neki a cetlit, nem. Ez esetben az, akit megkérek a levél továbbítására, a fizikai vagy adatkapcsolati rétegnek feleltethető meg, míg ami a cetlire kerül az átvivő számára értelmezhetetlen nyelven, megfeleltethető az alkalmazási vagy megjelenítési rétegnek.

Az SSL/TLS titkosítási és azonosítási feladatokat is ellát. Amikor arról van szó, hogy mennyire okos dolog mondjuk reptéri nyílt wifit használni netbankoláshoz vagy levelezéshez, alapvetően azért hülye a kérdés, mert ha SSL titkosítás mellett működik az adott webhely a böngészőbe, hiába hallgatja le a wifit valaki, az a kommunikáció, ami a laptop és a banki szerver vagy levelezőszerver közt bonyolódik, értelmezhetetlen adatmasszaként fog csak megjelenni, hiszen titkosított. [SSL/TLS-t viszont nem csak a böngésző használ! Lazán kapcsolódik, de ilyenkor ésszerűen azt kellene figyelembe venni, hogy a laptopon futhatnak olyan szolgáltatások, amik viszont sehogy sem titkosítanak. Okostelefonok pedig gyakorlatilag általános, hogy az appok erőforrásigényének csökkentése miatt számos alkalmazás egyáltalán nem használ titkosítást vagy csak nagyon gyengét, ami igencsak rizikós annak tudatában, hogy az okosmobilok többsége, hacsak nincs készenléti állapotban, automatikusan csatlakozik a nyílt hálózatokhoz, ha olyat lát, a mobil gyengén vagy sehogy sem titkosító szolgáltatásai és alkalmazásai pedig kapásból küldik is az adatokat a szervereik felé.] Akit a titkosítás pontos módja érdekel, itt olvashat róla. 

A titkosítással a gyakorlatban együtt jár, hogy egy, a kommunikációtól független, harmadik  fél előzetesen tanusítványt állított ki a szerver számára, ami igazolja, hogy ő tényleg az, akinek mutatja magát a kliens felé, akárcsak a szerver személyi igazolványa lenne. A böngészőprogramok pedig szintén tudják, hogy milyen típusú tanusítványokat fogadnak el és ha olyan tanusítvánnyal találkoznak, amivel valami nem stimmel, azonnal jelzik a felhasználó felé.

Visszautalva arra, amit a cikk elején írtam, ha a szolgáltató oldalán a DNS-szerver a névfeloldásokat hibásan végzi, a gyorsítótárában hamis hosztnév-IP-cím összerendelések vannak, ennek megfelelően téves adatot ad át a kliensnek, előfordulhat, hogy a http://bardoczi.net címen valamilyen kábszicsempész-gyilokpornós-fegyverkereskedős cég oldala jelenik meg. Ugyanez történik akkor is, ha a felhasználók  gépén az emlegetett hosts fájlokban valótlan párosítások vannak megadva, lényeg, hogy a felhasználó fejében meg sem fordul, hogy alighanem nem azt az oldalt látja, amit keresett.

Abban az esetben viszont, ha valaki a httpS://bardoczi.net címet látogatja meg, számos forgatókönyv elképzelhető, ha a DNS-kérés hamis. A jólnevelt böngésző azonnal jelez, hogy a domainnévhez tartozó certifikátumot a Comodo olyan módon állította ki, hogy a bardoczi.net hosztnévhez a 70.39.146.219 IP-cím tartozik, viszont a tartalom ennek ellenére mégsem erről a címről csorogna be, hanem teljesen máshonnan – teljesen más tartalommal. A felhasználónak lehetősége van arra kattintani, hogy vállalja a kockázatot és mégis betölti az oldalt, de csak annál a látogatásnál, minden újabb látogatásnál a böngésző erre újra rá fog kérdezni. Ami viszont tragikus, hogy a böngészők a mai napig lehetővé teszik, hogy egy-egy oldal "hamis személyivel" felkerüljön a kivételek közé, azaz a felhasználó minden látogatásakor a problémás certit elfogadja a böngésző, ami nem csak annyit jelent, hogy a felhasználó esetleg nem is azt az oldalt látja, amelyiket szeretné, hanem man-in-the-middle támadással más az egész adatforgalmat lehallgathatja. A certi részletei egyébként minden böngészőben lekérdezhetőek a címsor elején lévő lakatra kattintva.

Nos, képzeljük el, hogy valaki egyszer elfogadott egy hamis tanusítványt - vagy valaki, akivel közösen használják a böngészőt – ezen kívül a hosts fájl is meg van buherálva. Így előfordulhat, hogy hónapokon keresztül úgy használja mondjuk a gmail.com-ot, hogy azt valaki, akinek a szerverén keresztül megy az adat, aki a már említett közbeékelődéses támadással a felhasználó és a gmail.com közt áll, minden nehézség nélkül lehallgatja felhasználónévvel, jelszóval, a küldött levelek tartalmával, mindennel együtt! Az azonosításon kívül a titkosítás arra is kiterjed, hogy az adatfolyamot bizonyos méretű adatblokkonként ellenőrzi, hogy megfelelően titkosított-e, ha nem, figyelmeztet vagy eldobja a kapcsolatot menet közben.

Ha a böngésző tanusítványhibát jelez, annak ugyan lehet számos más oka is, de mindig mérlegeljünk előtte, hogy megéri-e a kockázatot, ha továbbmegyünk.  

Egyre több szervezet alkalmaz ún. UTM, azaz unified threat management megoldásokat aminek a lényege, hogy a biztonságot veszélyeztető szolgáltatásokat nem külön-külön küszöbölik ki. Azaz nem külön egy tűzfalas megoldás figyeli a hálózati forgalmat, egy antivírus megoldás kergeti a vírusokat, ezen kívül megint másik arra ügyel, hogy az alkalmazottak véletlenül ne küldözgessenek kifelé olyan információkat, amiket nem szabadna, hanem ezeket egy szolgáltatás suite-ba csomagolják. Itt ismét néhány egyszerűsítéssel fogok élni. Képzeljük el, hogy az elérendő célja az IT staffnak, hogy az alkalmazottak ne használjanak Yahoo Mail-t céges adatok átküldésére, de nem akarjuk elzárni őket a privát levelezésüktől sem. Azaz ezt valahogy ellenőrizni kell. Ekkor nincs mese, annak ellenére, hogy a Yahoo levelezője titkosított forgalmat bonyolít a szerver és az ügyfél közt, valamilyen módon meg kell figyelmi a forgalmat tartalmi szempontból olyan nyomok vagy mintázatok után kutatva, amik arra utalnak, hogy valaki nem túl bölcs módon mondjuk üzleti szempontból kritikus információkat küldözget, amiről tipikusan nem is tudja, hogy mennyire kritikus, csak azt, hogy a kollégának kényelmesebb átküldeni Yahoo-n, ha már úgyis oda van belépve. Megint más esetben ha már Facebookozik az alkalmazott, a forgalom titkosított ugyan, mégis ellenőrizni kell, hogy véletlenül se kattintson olyan linkre, amivel lefertőzi a céges gépet.

Van-e megoldás arra, hogy az alkalmazott magánszéfrája ne sérüljön, ugyanakkor mégis maradjon házon belül az az infó, amit házon belül szeretne tartani mondjuk egy vadászrepülőket tervező cég? A rövid válasz, ahogyan sejthető: nincs.

Ha valaki bele akarna fülelni a titkosított forgalomba, a böngésző azonnal jelezne, aminek annyira nem örülne a felhasználó. Mit lehet kezdeni azzal az adatfolyammal, ami titkosított? Nincs mese, fel kell oldani valahogy a titkosítást, dekódolni kell, megszaglászni, hogy nincs-e benne valamilyen kényes adat, majd titkosítani, de már a céges szerverrel és úgy továbbítani a  külső szerver felé. Ha a külső szerver persze észleli, hogy valaki belepiszkált az adatfolyamba, ennek megfelelően lehet, hogy egy olyan ködös hibaüzenetet dob, hogy nem felel meg a kapcsolat az elvárt biztonsági standardoknak, ezért vége a mókának. A webes szolgáltatások viszont nagyon sok esetben sokkal megengedőbbek, ha SSL-ről és certikről van szó, mivel tisztában vannak vele az üzemeltetők, hogy lehetnek olyan felhasználók is, akik annyira régi böngészőt használnak, amelyik az alkalmazott titkosítási módszert még nem támogatja megfelelően vagy olyan államból használnák a szolgáltatást, ahol a webes szolgáltató és az adott állam megállapodást kötött azzal kapcsolatban, hogy a felhasználóikat lehallgathatják. Kínában például így. 

Felmerül a kérdés, hogy mégis hogyan oldják meg a titkosított kapcsolat elemzését alkalmazó cégek azt elegánsan, hogy a felhasználók ne kapjanak figyelmeztetést, maximum törött lakat látszódjon a címsorban, ami azt jelzi, hogy titkosított a kapcsolat ugyan, csak a másik fél, azaz a szerver valódisága nem garantált? Úgy, hogy a céges gépre az előtelepített böngészőbe a célnak megfelelően megmókolt tanusítványok kerülnek, mivel tudható, hogy a magán kapcsolattartásra leggyakrabban használt webhelyek melyek és milyen certit használnak, amihez a cég hozzábiggyeszti a sajátját. Ezen kívül a cég saját DNS-szervereket használ, ami a szükséges oldalakat eltéríti.

Azért valami feltűnőbb nyoma csak van annak, ha gyakorlatilag hakkolva van az a technológia, amit arra fejlesztettek ki, hogy a kliens és a szerver tökéletesen bízhasson egymásban, nem? Igen, viszont olyan helyen, amit a felhasználó tipikusan soha az életbe nem néz meg. Ahogy már írtam, a címsor elején lévő lakatra kattintva, majd azon belül a tanusítvány részleteit kiválasztva jeleníthetők meg a szerver hitelesítésével kapcsolatos részletek. Ez például a LinkedIN esetén a Digicert által LinkedIN-nek kiállított tanusítvány, a Gmail esetén egy Geotrust/Google CA által Gmail-nek kiállított tanusítvány és így tovább. Abban az esetben, ha ettől eltérő tanusítványinformációkat látunk, akkor vagy a cég mókolt valamit, ahogy természetesen az sem zárható ki, hogy a céget egy kifinomult támadás érte, a támadó helyezett el  hamis certiket a böngészőben az alkalmazottak lehallgatására.

Biztonságtudatos felhasználónak tartod magad, de vezeték nélküli billentyűzetet használsz? Kínos. Avagy öreg trükk, nem vén trükk: a billentyűzet rádiójeleinek sniffelése.

A vezeték nélküli billentyűzetek elterjedésekor természetesen nem volt szempont és sajnos igény sem arra, hogy a billentyűzet és a vevője közti kommunikáció titkosított, pláne elfogadható mértékben titkosított legyen, ami egy sajátos helyzetet teremtett. Nevezetesen azt, hogy sokan titkosítják a gépükön tárolt adatokat millió meg egyféle módon, hardeningelik, ahogy tudják, ugyanakkor ha vezeték nélküli billentyűzetet használnak, az összes billentyűleütés tetszőleges távolságból lehallgatható, ráadásul úgy, hogy a géphez hozzá sem kell férni, csak egyszer a közelében elhelyezni egy praktikusan telefontöltőnek álcázott dobozt. Ráadásul bagóért összekalapálható a garázsban olyan eszköz, ami ezt lehetővé teszi.

A vezeték nélküli billentyűzetek lehallgatása olyannyira nem új műfaj, hogy komolyabban már 2007-ben is komolyabban foglalkoztak vele.

Néhány hónappal ezelőtt pedig Samy Kamkar olyan szájbarágósan írta le step-by-step, hogy hogyan építs billentyűzetpoloskát, hogy azt tényleg szinte mindenki megérti, aki meg tud különböztetni egy USB-csatlakozót a lyukkártyától. Az elektronikában ugyan nem vagyok otthon, de a neten fillérekért rendelhető apró elekronikai kütyük gyakorlatilag úgy működnek, mint a legó és mindhez kimerítő mennyiségű dokumentáció áll rendelkezésre, viszont még csak nem is nekünk kell kitalálni, hogy milyen alkatrészekkel érdemes valamit megvalósítani és a szoftvert hozzá faragni, hiszen már ezt is rég kiagyalták a műfaj szerelmesei. A blogposzt szerint 80 dollárból összedobható, mobiltöltőnek álcázott eszköz folyamatosan figyeli a hatótávolságában lévő vezeték nélküli billentyűzetet és ami a legszebb az egészben, hogy egy kezdetleges GSM modul gondoskodik arról, hogy mindezt egyszerű mobilhálózaton keresztül továbbítsa a megfelelő helyre. Akár egy kémfilmben, nem?

Az alapvető probléma azon túl, hogy a vezeték nélküli billentyűzetek egy része vagy nem alkalmaz semmiféle titkosítást vagy alkalmaz ugyan, de az olyan bénán van megvalósítva, hogy könnyűszerrel dekódolható, a billentyűzet pedig az az eszköz, amire a felhasználó talán legritkábban gondol úgy, mint ami az adatai integritását esetlegesen veszélyeztetheti.

Én személy szerint már évek óta már jóideje éppen ezért nem használok vezeték nélküli billentyűzetet, ami pedig volt, stílusosan lepasszoltam egy volt korábbi, szomszéd szobában lakó lakótársamnak talán szülinapra :)

A kockázat kiküszöbölése meglehetősen egyszerű: ne használjunk vezeték nélküli billentyűzetet, hacsak nem sajnáljuk a pénzt olyanra, ami normálisan titkosít és persze ennek megfelelően  eszelősen drága. Nem csak kritikus környezetekben, hanem olyan helyekről is száműzni kellene a wireless billentyűzeteket, mint például egyetemi vagy akadémiai kutatóintézetek, szerkesztőségek és persze illene néha szétnézni, hogy nincs-e valami olyan mobiltöltőnek tűnő valami a konnektorba csatlakotatva, amiről nem tudni, hogy kié és micsoda. Ugyanis ha bagóért összeállítható ilyen sniffer, ahol a támadónak csak egyszer kell fizikailag a megfigyelendő billenytűzet közelében lennie, hogy az adott irodában csatlakoztassa a kütyüt az egyik konnektorba, valamivel drágábban  kapható olyan is, ami mondjuk nem csak a szomszéd szobából, de jóval nagyobb távolságból is képes a billentyűzeteket megfigyelni, tudva, hogy ami 2,4 GHz-s frekvencián muzsikál, az szinte biztos, hogy egy vezeték nélküli billentyűzet, összevetve azzal, hogy a billentyűzetekre nyilván jellemző, hasonló hullámhosszon működő Bluetooth vagy Zigbee-eszközök megkülünböztethető módon adják a jeleket.

Arról, hogy hogyan barkácsoljunk egy hétvége alatt billentyűzetpoloskát, olyan kimerítő leírást ad az eredeti poszt és videó, hogy ahhoz nem is tudnék mit hozzátenni.

Megjegyzem, ahogy a titkosított kommunikációt folytató eszközökre általánosan jellemző, a vezeték nélküli billentyűzetek némelyikében is elkezdtek alkalmazni egyfajta obfuszkációs technikát, aminek a lényege, hogy a billentyűzet akkor is dobál jeleket, amikor egyébként nem gépel rajta senki vagy éppenséggel gépelés közben olyan jeleket is lead, amit majd a vevője nem vesz figyelembe, ez értelemszerűen olyan eszköznél csak korlátozottan megoldható, hiszen a számításigényesebb titkosítás és a kamu-jelek küldése nem csak erősebb beépített hardvert követelne, hanem az elemet is gyakrabban merítené.