Svédül tanul az Outlook

Sokan tapasztalhatták, és a következő napokban még fogják is, hogy a Microsoft egy félresikerült frissítésének köszönhetően most fél Európa svédül tanul alapfokon. Nem mindenki, mert az olaszok portugál nyelvre panaszkodnak, ahogy a távolabbi keleten is egyeseknek portugálul jelentkezett be az Outlook-ja.


A problémát két keddi frissítés okozza, melyekben az Outlook 2007 és 2010-es verziója érintett. Az online fórumokon sokan keresték rá a megoldást, ami a KB4011086 (Outlook 2007) és a KB4011089 számú frissítés eltávolítása, majd letiltása a Windows Update beállításai alatt. Ez ugyanakkor nem javasolt a Microsoft szerint, mivel egy nagyobb biztonsági frissítés részeként érkezett. Sokan erre legyintenének, mivel nagyon kevesen vesznek tudomást idő előtt a kihasználható hibákról, ugyanakkor itt egy picit más a helyzet, a frissítés publikálásával ugyanis a rosszindulatú hozzáértők vissza tudják fejteni, hogy mely problémára akart megoldást nyújtani az adott frissítés, így egy ilyen csomag publikálásával nyilvánossá válik a biztonsági rés is. A másik probléma, ami miatt érdemes lehet picit várni, hogy sok esetben a mappák is átnevezésre kerültek, melyek a frissítés eltávolításával nem állnak vissza maguktól. Remélhetőleg a kiadásra kerülő javítás megoldja majd ezt a problémát is, akinél viszont már nincs fent a hibás csomag ott korántsem biztos, hogy ez működni fog.
A vállalkozó kedvűek a vezérlőpultban a telepített frissítések alatt eltávolíthatják a fentebb megadott csomago(ka)t, ezzel helyreáll a nyelv egy újraindítás után. Ha ez megtörtént a Windows Update alatt egy jobb kattintással el kell rejteni az adott csomagot, így a Windows nem próbálja többet telepíteni.
Aki úgy érzi együtt tud élni néhány napot, esetleg 1-2 hetet a problémával (egyelőre nincs ígéret az MS részéről mikor lesz javítás), annak érdemes lehet kivárni, amíg egy újabb patch javítja majd a nyelvet.
Addig sajnos nincs mit tenni, esetleg meg lehet tanulni pár szót svédül:
från – tól
till – küldő
kopia – másolat
hemlig kopia – titkos másolat
meddelande -üzenet
skicka – küldés
ämne -tárgy

Egy témával kapcsolatos angol nyelvű fórum: https://social.technet.microsoft.com/Forums/office/en-US/72037dce-f8bb-475f-8f2d-4af6b3a9ea88/latest-outlook-2007-security-patch-kb4011086-is-wrong-patch-is-change-app-language-to-swedish?forum=officeitprolegacy

A fórum nyitó posztjában található egy olyan parancssor is, amit egy .bat fájlba kimásolva kicsit automatizálhatjuk is a folyamatot. Ez már egy kicsit komolyabb szakértelmet kíván, de nagyobb mennyiségű problémás géppel rendelkező ügyfeleknél sokat segíthet a tömeges eltávolításban.

Bár sokan mulatságosnak találhatják a problémát, sajnos nem mindenkinek az. Azért a végére két pozitívumot is mondhatunk. Egyrészt sosem lehet tudni mikor ment életet pár svéd szó, amit most megtanulunk, a másik pedig, hogy még egy svéd sem panaszkodott. 🙂

Trevlig dag för alla dina läsare och lycka till att ta bort uppdateringen!

Mindent a spam-ekről, hasznos tanácsokkal

Napjaink egyik legidegesítőbb és egyben nem kevés veszélyt magában hordozó internetes jelensége a spam-elés. Ennek fogjuk most több témáját részletesen érinteni. A cikk végére választ kaphatnak olvasóink a hogyan, miért és miként kérdésekre is, végül összeszedünk néhány nagyon hasznos tanácsot spam-ekkel kapcsolatban, megnézzük felhasználói oldalról mit lehet tenni a probléma ellen.

Spam áradat

A spam szó eredete

Bármilyen furcsa az eredeti szó az angol löncshúsból ered (spiced pork and ham), és a Monty Python Repülő cirkuszának egyik epizódja ihlette, hogy a kéretlen leveleket erről nevezték el. Ebben a darabban rendszeresen ezt a löncshúst szolgálták fel minden étkezésnél és a szereplők a spam szó kiabálásával lázadtak ellene, innen terjedt el a kéretlen szó szinonímájaként.

Hogyan működik

A rövid kitérő után lássuk azt, hogyan is jutunk el oda, hogy egy spam levél landoljon a postaládánkban.  Ennek számtalan lehetséges oka van. Elsőként talán a leggyakoribb jelenség, amit sokan elkövetnek, hogy weboldalakon nyílt szöveges formában kint van az e-mail címük, netán abban a még jobban felismerhető formában, amikor rákattintva a címre a levelezőprogram is nyílik és a funkció nincs Javascript kóddal levédve. Ez a biztos út a spammerek listájára kerüléshez. A robotok a @ jelet vadászva a neten gyorsan rábukkannak a címre és már be is gyűjtik egy adatbázisba, ahonnan kapjuk is hamarosan a spam-et. (Ezért van sok helyen a (a) vagy a (kukac) írva inkább a mail címekhez.) Az ilyen adatbázisokat pedig sokan pénzért adják-veszik a neten, jó pénzért azokat, amelyekben visszaigazolt és garantáltan működő mail címek vannak. Azt, hogy ezt honnan tudják máris eljutottunk a következő hibához. Túl azon, hogy a fogadó e-mail rendszert többféleképp is be lehet állítani (spam esetén csendben dobja el a levelet, netán verje át a feladót, hogy a címzett nem létezik, stb.), ha már egyszer beérkezett az a levél a postafiókba, akkor két súlyos típushiba is van, amit a felhasználók rendre elkövetnek. Ha valamilyen izgalmasnak vélt dolog érkezik a kéretlen levélben máris rákattintanak a levelező programban a képek megjelenítése opcióra. Csakhogy a levelezők nem azért tiltják le ezeket, hogy minket szivassanak, hanem mert a levelekben található képek webes linkek formájában találhatóak meg, tehát a küldő szerverén várnak megnyitásra. Ez még önmagában nem is lenne ártalmas, de mivel ezeket a HTTP kéréseket úgy is le lehet programozni, hogy a kép megjelenése közben egy paraméterben a küldő azonosítóját is elküldi így máris tudják, hogy ki az aki megnyitotta az üzenetet. A spammelő adatbázisában máris egy kis bit átbillen, ami jelzi nekik, hogy a levél célbaért. Innen pedig egyenes az út arra az értékes listára, amit utána lehet nem sokkal később pénzért vesz meg valaki más, hogy szintén kéretlen leveleket küldjön nekünk. Aztán jön a másik tipikus hiba, a leiratkozás vagy unsubscribe linkre kattintás. Teljesen mindegy a megnyíló weboldal mit ír ki nekünk, ha spam levélben ilyenre kattintunk abban biztosak lehetünk, hogy le nem iratkoztunk semmiről, viszont megerősítettük nekik az e-mail címünket, tehát éppen ellenkező hatást értünk el, ettől csak több spam fog jönni. Ugyanezt a hatást elérhetjük a csatolmányokra kattintgatással is, igaz ott inkább a vírusfertőzés esélye a nagyobb, a csatolmánnyal ellátott spam-eket rendszerint azzal a céllal küldik. Itt pedig eljutottunk oda miért is kritikus, ha sok a beáramló spam.

Jogi háttér

Természetesen a kéretlen levelek küldése a világ legtöbb országában bűncselekménynek számít, amit a törvény büntet. A bűnüldöző szervek hatékonyságról szintén lehetne egy külön cikket írni, így ebbe nem mennék mélyebben bele. Amit itt érdemes megemlíteni, hogy számtalan olyan spam szerverről hallani, amire be van programozva a spamküldés, be vannak állítva a jól fizető megrendelőktől a hirdetések, majd a szerver tárva-nyitva van a látogatók előtt, az ún. admin felület nyíltan elérhető. A kíváncsiskodók gyakorlatilag amikor rálelnek egy ilyenre, akkor maguk indítanak el egy-egy ilyen spam folyamot, így persze kérdéses a felelősség is, hogy ki küldte a spam-et, aki a rendszert beprogramozta, vagy aki lenyomta rajta a gombot amikor arra járt. A végeredmény szempontjából nekünk felhasználóknak ez mellékes, mindenesetre ez is egy érdekes jelenség.

A szűrés

Most egy kicsit technikaibb rész következik. A spamszűrésnek rengeteg féle módja van, nagyon sok féle módon és ponton lehet védekezni ellene. Fontos hangsúlyozni, hogy nincs a világon olyan rendszer, ami 100%-os biztonsággal dolgozik, tehát soha nem dob el egyetlen nekünk fontos levelet sem, illetve soha nem enged át számunkra spam-nek minősülő levelet. Ez a feladat ugyanúgy lehetetlen, mint ahogy egy portásnak is akármennyire definiáljuk kit engedhet be és kit nem, ha az a valaki kellően jó dumával érkezik a portást kicsit megvezetve ugyanúgy be fog jutni hozzánk. Ugyanígy működik a spamszűrés is, és a példából jól látszik az is, hogy minél nagyobb mintából, minél jobban specifikált paraméterekkel dolgozunk annál pontosabb lesz a végeredmény. Ebből adódóan a nagyobb multi cégek levelezőrendszerei alapvetően jobban fogják tudni szűrni a spam-et, hiszen nagyobb mennyiségben találkoznak vele, jobban be tudják határolni melyik spam és melyik nem, a felhasználói visszajelzésekből is jóval több van (ha egy küldő levelét sokan olvasás nélkül kukázták azt nyilván egy idő után blokkolni kezdik, stb.), így aztán a szűrés is sokkal kifinomultabb, könnyebben tanulnak az automatizált algoritmusok is. A saját üzemeltetésű rendszereknél nyilván sokkal kisebb lesz a minta és nem vagyunk birtokában sem annak a tudásbázisnak, hogy tudjuk mit is kéne kiszűrnünk. Persze alkalmazhatunk többféle szűrési megoldást, így például megadhatunk a rendszernek adott kulcsszavakat, megmondhatjuk mely feketelistákon lévő küldőktől ne fogadjon leveleket, állíthatunk fel fehérlistát (akiktől minden esetben fogadjon levelet a rendszer), pontozási rendszert állíthatunk fel különböző szabályok alapján (SCL), és így tovább. Ezek a lehetőségek adottak a legtöbb levelezőszerver esetében. Aztán a következő védelmi vonal a vírusvédelem. Ebből létezik olyan, amelyik szerver oldalon is végez szűrést és olyan is, amelyik csak a kliensen, tehát előbb letöltődik a levelezőprogramba a levél és csak ott dobja ki. Természetesen a vírusirtók a spamszűréssel együtt vírust is ellenőriznek, így kettős feladatuk is van. A spamszűréssel is ellátott vírusirtó esetében megint ugyanaz a helyzet, hogy éves díjas alapon megvásároltuk a gyártótól azt a tudásbázist, ami alapján egy szoftver el tudja dönteni egy levélről, hogy az spam vagy sem. Ők is alkalmaznak feketelistákat, akár sajátot is, és különböző szabályok alapján szűrik ki a leveleket, amiket a központban csiszolgat egy csapat folyamatosan és a változtatásaik hatással lesznek a mi levelezőrendszerünkre is. Nyilván ezt saját magunknak megvalósítani ugyanilyen hatékonysággal nem lehetséges, amikor ugyanis egy módosítást végzünk vagy egy adott küldőt kitiltunk akkor csak a saját rendszerünkben fog az szűrésre kerülni. Ugye mennyivel jobban megéri egyszerre nagyon sok helyen változtatni?

Sajnos nagyon sok olyan esettel találkozni, amikor annyira kifinomult módszereket alkalmaznak, amikor szinte lehetetlen enélkül a “licencelt tudás” nélkül leveleket kiszűrni. A legújabb módi, hogy valakik beregisztrálnak több tucat domain nevet (kb. 2-3 ezer forint / darab), azokhoz egy szolgáltatónál megvesznek több tucat IP címet, majd a szervereikről valós domain alól elkezdik ömleszteni a spamet. Közben hol az egyik, hol a másik IP címről és domainről érkezik a levelezőrendszerhez a spam, azokat a kulcsszavakat, amikre pedig blokkolásra kerülhetnének (pl. a Rolex helyett R0lex, Roleex, Rollex, R0llex, Ro lex, Ro.lex, R.lex, stb.) szintén variálja egy automatika, így látszólag több különböző címről jön, nem ugyanolyan tartalommal és a különböző visszaellenőrzéseken (valós-e a domain, az az IP cím tartozik-e hozzá, stb.) is átmegy. Persze a domain-ek fiktív személyek nevein vannak, holland szerverről jön a levél, a domain tulajdonos egy moszkvai cím, magánember, a másik cím panamai, a harmadik Argentínából jön és így tovább. Gyakorlatilag lehetetlen megfogni. Viszont ha egy nagy cég összegyűjti ezeket az adatokat, akkor gyorsan kiderül, hogy a két spam beérkezése közt eltelt mondjuk 1 órában a küldő több millió spam levelet küldött ki, melyeket a felhasználók spam-nek jelöltek, vagy szimplán kidobtak, így a következő körben már nem fogunk levelet kapni, a szoftverünk letiltja azt.

A szerver oldali és kliens oldali szűrés lényegében ugyanúgy képes működni, csak míg az egyik a szerver oldalon elintézi mindezt, addig a másiknál előbb le kell töltődjön az a levél, hogy a kliens oldali védelem meg tudja vizsgálni és ha spam-nek ítéli a megfelelő mappába áthelyezni. Így a szerver oldali megoldás biztonságosabbnak is tekinthető és sok spam esetén az adatforgalomban is érezhető a pozitív hatása.

Természetesen a szűrés és annak eldöntése, hogy az adott levél spam-e, illetve vírusos-e egy komoly hardverigényes feladat is lehet, hogyha nagyobb mennyiségű postafiók nagyobb mennyiségű levelét kell átnézzük, esetleg sok a beáramló spam. Ilyenkor vannak olyan esetek, amikor már a levélszerverre beáramló leveleket is szűrik. Vagy a levélszervernek egy speciális fajtáját telepítik egy külön gépre a levelek előszűrésére (front-end), és/vagy elé tesznek egy tűzfalat, ami már egy szűrést elvégez. Például elfogadott dolog az is, amikor egy európai cég nem vár EU-n kívülről semmilyen levelet, legfeljebb amerikai gyártóktól, így a tűzfalon geo adatbázis szűréssel kikapcsolásra kerül mindennemű forgalom, amit Észak-Amerikán és Európán kívülről kezdeményeznek felénk. Persze ezt lehet a levélküldésre magára is alkalmazni vagy minden egyéb másra is, a spam-ek és az internet felől érkező támadások kb. a negyedére csökkenthetőek csak Dél-Amerika, Kína és Oroszország lekapcsolásával.  Ezzel lényegében innen semmilyen levél nem jön be, a küldők számára ismeretlenek vagyunk és a levélszemét szűrőről is leesik a teher. Ilyen funkciókat akár ingyenes linuxos rendszerekből is ki lehet hozni, persze azoknál jóval korlátozottabb és kevésbé naprakész sajnos a tudásbázis.

Hogyan kerülhetünk mi magunk tiltásra

Ez is szorosan a témához kapcsolódik és habár kicsit más jellegű probléma, de erről is ejtenünk kell néhány szót. Sok olyan eset is volt az elmúlt években, amikor ügyfél azzal keresett meg minket, hogy visszapattannak egyes címekre küldött leveleik, esetleg csak nem érkeznek meg. Ilyenkor meg kell vizsgáljuk ki az SMTP szerver, amivel küldünk, annak mi az IP címe és az szerepel-e valamelyik feketelistán. Ennek ellenőrzésére mi az mxtoolbox.com-ot szoktuk használni, nagyon jól működő szolgáltatásuk van.  Rendszerint ha a visszapattanó üzenet arra utal vagy csak egyes címzettekhez nem megy el a levelünk, akkor felkerültünk valamelyik ilyen feketelistára. Ha az SMTP szerver a szolgáltatónké akkor jelezni kell egyből feléjük, de jó eséllyel nagyon rövid időn belül ők maguk veszik észre és javítják, de ha túl sokszor és sokáig fordul ez elő ott a szolgáltatónál is nagy bajok vannak. De nem kell csodálkozni ezen, a t-online.hu szerverei, a Freemail, de még akár a Gmail is felkerül néha egy-egy ilyenre. Saját szervernél viszont magunknak kell gondoskodni az eltávolításról. Fontos, hogy ez csak akkor történjen, amikor már az okot megszüntettük.

Az okok általában nagyon egyszerűek. Vagy minden rendben van csak nagyobb mennyiségű levelet küldtünk ki és valamelyik rendszer besokallt, de a leggyakoribb, hogy valami olyan vírust kaptunk, ami spam-et küld rajtunk keresztül kifelé. Ezt előbb rendezni kell és utána eltávolítást kérni, különben még jobban pórul járhatunk. A másik gyakori módja a feketelistára kerülésnek a feltört weboldal kódok, rendszerint a valamilyen nyílt forrású (WordPress, Drupal, Joomla és társaik) CMS rendszer biztonsági hibája, amik miatt ezek a rendszerek napi frissítést igényelnek. Gyakran tartalmaznak olyan sérülékeny kódokat, amiket egy erre szakosodott támadó meghívva a mi szerverünket tudja spamküldőnek használni. Ő kiküldi a spam-jeit, minket pedig letiltanak egyes szolgáltatók. Ebben az esetben is előbb a rést kell befoltozni és utána kérni az eltávolítást.

Mit tehetek felhasználóként a spam-ek ellen

Végül egy gyors összefoglalás a fentebb leírtakból, mert azért a felhasználó kezében is van néhány egyszerű fegyver a spam-elés ellen:

  • kéretlen levelekben sose engedélyezzük a képek letöltését
  • ne nyissunk meg ismeretlen feladóktól érkező csatolmányok és figyeljünk oda a feladó neve mellett a feladó e-mail címére is, ha bármi gyanúsat észlelünk mehet is a kukába a levél
  • a legtöbb levelező kliensben (pl. Outlook-ban, Thunderbird-ben), de a webesekben (pl. Gmail) is van lehetőség leveleket spam-nek jelölni. Ha ilyen levél érkezik ezt tegyük meg, mert a levelezőt tanítjuk vele. Egyes levelezőprogramokban pedig azt is megmondhatjuk a levélre jobb gombbal kattintva, hogy az adott feladót vagy annak domain-jét a megbízhatók listájára tesszük-e vagy éppen a blokkoltakhoz.
  • ügyeljünk  rá, hogy a mail címünk soha semmilyen weboldalon ne szerepeljen védtelen formában. Ha a weboldal kódjában  a mailto: mailcimem@domainem.hu szerepel akkor azt úgy vehetjük mint egy “ide lőjenek” táblát.
  • lehetőség szerint ne regisztrálgassuk össze-vissza mindenféle ismeretlen vagy kétes weboldalon a mail címünket különféle szolgáltatásokhoz. Rendszerint marketing levelekre, spam-elési célra használják majd fel, az is elég idegesítő tud lenni, ráadásul felkerülhetünk vele olyan listákra is, ahonnan rengeteg spam-et fogunk kapni. Mivel rengeteg ingyenes levelező érhető el, inkább regisztráljunk egy külön címet az ilyenekre, ha már mindenképpen meg kell adjuk az ilyen regisztrációkhoz használjuk azt. A Gmail vagy a Microsoft levelezői például egészen jól szűrik a bejövő spam-eket, így a “spamgyűjtő” fiókunk még egész tiszta is maradhat, miközben a cégest sem terheltük túl.
  • használjunk jó spamszűrő képességekkel is megáldott kliensoldali vírusvédelmet, ami beépülő modulok segítségével akár egészen hatékonyan is meg tudja szűrni a leveleket, kiegészülve a kliens program spamszűrési képességeivel, amivel egy jó program rendelkezik. Ide tartozik az is, hogyha Outlook-ot használunk frissítsük rendszeresen, mert a Microsoft gyakran ad ki frissítést hozzá, a kliensoldali spamszűrés további javítására.

Reméljük cikkünkkel sok felhasználónak tudtunk hasznos tippeket adni és ezzel javítani a humán spamszűrő képességeket. Kövesse weboldalunkat és Facebook oldalunkat, így mindig elsőkézből értesülhet új cikkeinkről és juthat újabb hasznos információkhoz. Ha kérdése vagy észrevétele van, esetleg szeretne témát ajánlani ne habozzon, írjon nekünk!

Az eddigi legpusztítóbb zsarolóvírus – WannaCry

2017. május 12-én egy új vírus kezdett terjedni futótűzként a világhálón, egy szerencsés véletlennek köszönhető, hogy nem okozott akkora katasztrófát, mint amekkorát csak az amerikai akciófilmekben lát az ember a moziban. Ez a vírus több szempontból is különleges, kiemelkedik a zsarolóvírusok közül, melyekből mára már 12 egy tucat, most mégis tudtak újat mutatni. A veszély még nem múlt el teljesen, de szerencsére vannak egyszerű praktikák, amikkel a nagy pusztítás megelőzhető. “Sírni tudnék” mondja a magyar, amikor valami szívszorító sokk éri, vélhetően erre utal az angol WannaCry név is, ami némi amerikai szlenggel fűszerezve röviden összefoglalja a valóságot. Az a hálózat, amelyik védtelen és megkapja ezt a vírust ott azt a napot garantáltan meg fogja könnyezni valaki…

A titkosszolgálati előzmények

Mára már nyílt titok, amióta Edward Snowden kiborította a bilit, hogy az amerikai titkosszolgálatok 2001. szeptember 11. óta mindent a felügyeletük alatt akarnak tartani. Az akkori események hátterébe ne menjünk bele, ez a cikk nem az összeesküvés elméletekről fog szólni, mégis fontos háttérinformáció azoknak, akik nem ismerik az ilyen jellegű problémák hátterét. Tehát az akkori eseményeket meglovagolva, vagy arra hivatkozva az amerikai törvényhozás kötelezni kezdte a gyártókat, hogy hagyjanak kiskapukat a szoftvereikben, amit kihasználva az amerikai titkosszolgálat hozzáférhet bizalmas adatokhoz, amikor a szükség úgy kívánja. Ebben a problémában érintett aztán mindenki, nem csak a legnagyobb szoftveróriás Microsoft, az Apple, a Google, de az átlag felhasználók körében kevésbé ismert nagy biztonsági és hálózatos cégek, Cisco, Symantec és mindenki más is. De a Linuxot se hagyjuk ki a felsorolásból, szakavatottak biztosan hallottak korábban az IPSec botrányról, ami a törhetetlennek vélt titkosítás mesterséges gyengítéséről szólt, így az NSA hozzáférhetett az erősen titkosított adatforgalomhoz. Ehhez hasonló a mostani probléma is, egy olyan elrejtett sérülékenység került rossz kezekbe, amelynek kihasználására valaki vírust írt. Azt nem tudni pontosan, hogy az NSA egy szándékosan elrejtett kiskaput használt ki (előfordulhat ez is), mindenesetre az is előfordulhat, hogy az NSA talált és eltitkolt egy hibát a Windows-okban (a Microsoft egyébként ezt állítja), amit az XP-től kezdődően egészen az új verziókig megtalálhatunk bennük. Ami viszont biztos, hogy ez nemrégiben kitudódott, a Microsoft pedig válaszul biztonsági frissítés formájában befoltozta a lyukat még márciusban. Ezt az EternalBlue néven ismerté vált sérülékenységet aztán kerek 1 hónappal ezelőtt egy ShadowBrokers néven ismertté vált csoport tette közkincsé a neten, amit 1 hónapra rá most egy bűnözői csoport zsaroló vírusok terjesztésére használt fel. Ugye milyen akciófilmbe illő? Pedig ez nem egy Bruce Willis filmben játszódik, hanem most, ma, a valóságban!

A vírus terjedése, működése

A titkosszolgálati szál mellett a másik különlegessége a vírusnak az a terjedési mechanizmusa. Az átlag zsarolóvírusok egyszerűen megérkeznek egy vírusos levél csatolmányában vagy maga a letöltőkód, ami aztán leszedi a netről a gépünkre a vírust, majd miután elvégezte a dolgát és letitkosított mindent a gépünkön, megjelenít egy üzenetet és felszívódik. Eddig a pontig a WannaCry sem tesz másként. Innentől válik viszont izgalmassá és igazán veszélyessé. A vírusnak van ugyanis egy féreg (worm) típusú modulja, ami egy olyan vírus típus amelyik valamilyen hibát kihasználva terjed szét a hálózaton. Ilyen hiba a mostani Windows sérülékenység is, ami az SMB protokoll hibáját használja ki, ennek köszönhetően minden olyan gépet képes a vírus befertőzni amelyik a vírusgazdával egy hálózaton van és nyitva vannak rajta a fájlmegosztás portjai. Pedig ez a gépek többségén nyitva van, főként céges gépek esetében, szervereknél pedig néhány kivételtől eltekintve szinte mindig. A terjedés nem igényel semmilyen hozzáférést, mivel protokoll szinten van a hiba így a gépünk úgy fertőződik be, hogy közben jogosultságok szintjén minden a legnagyobb rendben van. A korábbi zsarolóvírusok esetében mindig elmondtuk, hogy a megelőzés és a mentés a két legfontosabb kulcsszó, a megelőzés ezúttal is nagyon fontos, de a mentéssel itt akad egy kis baj. Ha a vírus megfertőzi azt a központi gépet, amin a mentésünk van, márpedig ha az adott Windows sérülékeny, akkor meg tudja, vélhetően a mentésünkre is keresztet vethetünk. A világ számos országában cégek tömegei dőltek össze, angliai kórházakban szünetel az ellátás, informatikusok tömegei dolgoznak jelenleg is a károk helyreállításán, még annak ellenére is, hogy hamar sikerült gátat szabni a terjedésének.

Szerencsére a vírusban is van hiba

Ahogyan a világon minden szoftverben, úgy a vírusokban is van szerencsére hiba. A Wannacry első változata sem mentes szerencsére tőle. Egy szerencsés angol informatikus, aki egy vírusokkal foglalkozó blogot vezet már sokadjára regisztrál be ilyen víruskódokban megtalálható domain neveket azzal a céllal, hogy megvizsgálja az azokra indított adatforgalmat, amiből sok információhoz hozzá lehet jutni. Ezúttal is talált egy ilyen domain nevet a vírus kódjában, amit beregisztrálva egyszer csak leállt a nemzetközi nagy támadáshullám. Akkor jöttek rá, hogy a kézzel véletlenszerűen begépelt domain nevet a vírus egy ellenőrzés részeként használja. Ha nem létezik (márpedig eddig nem létezett), akkor folytatja a terjedést, ha létezik akkor leáll és nem küldi magát tovább. Miután a cím regisztrálásra került azt vették hát észre, hogy a világon mindenhol megállt a továbbterjedése. Ez nagyon sok ember nagyon sok munkáját, adatát mentette meg a világban, de mielőtt a túlzott optimizmus hibájába esnénk jegyezzük meg, hogy a veszély nem múlt el csupán időt és esélyt kaptunk arra, hogy felkészüljünk egy újabb, akár sokkal pusztítóbb körre, ahol a következő vírus verzióban nem lesz ilyen “kikapcsoló gomb”.

A megelőzés

Itt lényegében minden olyat felsorolhatnék, amit a korábbi zsarolóvírusok kapcsán már felsoroltunk. Elsőként emelném ki a tudatos felhasználást, amivel a kockázat nagyban csökkenthető, tehát nem nyitunk meg gyanús csatolmánnyal ismeretlenektől érkező leveleket és mindig figyelünk, hogy egy jó minőségű és naprakész vírusvédelem legyen a gépünkön. De sajnos nem csökkenti nullára a kockázatot ez sem és ez pont annak köszönhető, amit fentebb már leírtam, a vírus protokoll hibát használ ki és nem igényel jogosultságokat az adott gépen. Ebből az következik, hogy elég egy hálózaton lenni a fertőzött géppel és kész a baj. Csak két jellemző veszélyforrást említsek, ha egy nyilvánosan használt ügyfél WIFI-n egy hálózaton vannak a céges gépek és az egyik ügyfél vírust kap az fertőzi a céges hálózatban lévő gépeket is. Azért az otthoni felhasználónak is tudok ilyet mondani, ha a szomszéd használja a WIFI-t az ő nemtörődömsége is súlyos következményekkel járhat. Egyetlen megoldás erre a problémára a gépek frissítése a Microsoft által kiadott biztonsági frissítésekkel.

A következő Technet oldalon részletesen összefoglalják melyik Windows verzióra melyik frissítés(ek) foltozzák a kritikus hibát:

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Ennek megfelelően a Windows 7-et használók számára a KB4012212 és KB4012215 frissítések nyújtanak megoldást, Windows 8.1-hez a KB4012213 és KB4012216-os frissítések, Windows 10-nél pedig a KB4012606, KB4013198, KB4013429 frissítések verziótól függően. Ezt legegyszerűbben úgy tudjuk leellenőrizni, hogy a start menüben elkezdjük begépelni: telepített frissítések megjelenítése. A megjelenő vezérlőpult panelen felsorolja a Windows a korábban telepített frissítéseket és ha a felsoroltak valamelyike köztük van, akkor a gépünk már védett a külső támadással szemben, már csak magunknak kell odafigyelni, hogy egy vírusos levéllel nehogy elszabadítsuk a gépünkön.

Fontos eleme a megelőzésnek, hogy naprakészen tartott, működő vírusvédelem legyen a gépünkön. Az általunk ajánlott GData megoldások például már az elsők között felismerték az új vírust, ahogyan arról a gyártó blogja is beszámolt: https://blog.gdatasoftware.com/2017/05/29751-wannacry-ransomware-campaign

A Microsoft saját vírusirtója, a Windows Defender szintén felismeri a vírust, így ha működik a gépen és naprakész állapotban van szintén jók az esélyeink megelőzni a bajt még akkor is hogyha élesben is szembe kerülünk vele.

A Nemzeti Kibervédelmi Intézet egy részletes cikkben beszámol a vírusról és szintén adnak még számos hasznos tippet a védekezésre: http://www.cert-hungary.hu/node/370

A probléma nagyságát jelzi az is, hogy a Microsoft a régóta nem támogatott XP rendszerhez is kiadta a hibát befoltozó frissítést, amit ezen a linken lehet a gyártó oldaláról letölteni: http://www.catalog.update.microsoft.com/Search.aspx?q=KB4012598

Ha már megtörtént a baj

Legegyszerűbb a fertőzött gépet azonnal kikapcsolni vagy kihúzni a konnektorból és szakértőhöz fordulni. Ha már az üzenet megjelent a gépen, akkor a vírus végzett a fájlok titkosításával és vélhetően éppen a hálózaton történő terjedésen dolgozik. Itt már nagyobb kárt nem szenvedhet a gépünk, akár nyugodtan a konnektorból is kihúzhatjuk, de legalábbis a számítógépes hálózatról azonnal válasszuk le! Ez történjék a kapcsolat fizikai leválasztásával, tehát a hálózati kábel (UTP) kihúzásával vagy a WIFI hardveres kapcsolóval történő letiltásával. Amíg a gépen a vírus jelen van ne kössük újra hálózatra. Szerveres környezetben ha a gépünk vírust kapott és nem vagyunk 100%-ig biztosak abban, hogy a szerver SMB protokollja védett akkor ugyanezt tegyük meg a szerverrel is, tehát a hálózati kábelt húzzuk ki belőle és kérjünk szakértőtől segítséget, aki csak azt követően fogja újra üzembe helyezni a gépet, hogy a hálózat vírusmentességéről meggyőződött. Vélhetően a fertőzött gépeket tökéletesen helyreállítani csak egy újratelepítéssel lehet majd, de amíg ez nem történik meg sehol se kössük hálózatra a fertőzött gépet, mert mindekit veszélynek teszünk ki magunk körül.

Néhány utószó a karbantartások szükségességéről, a rendszergazdai háttér fontosságáról

Az elmúlt években, amióta a zsaroló vírusok megjelentek számos adatvesztésnek lehettünk szemtanúi. Szerencsére az általunk üzemeltetett számtalan rendszeren két ilyen vírustámadás fordult mindössze elő az évek alatt, mindkét esetben 0 bájt adatvesztéssel járt a mentéseknek köszönhetően, mindössze néhány óra adminisztrátori munkát igényelt csak a helyreállítás. Köszönhetően a megfelelően kialakított mentésnek, a megfelelő jogosultságoknak. Vélhetően az esetek relatív alacsony száma pedig a  megfelelő vírusvédelemnek volt köszönhető, mivel a vírusirtók és a levélszerverek naplóiban telis-tele van minden törölt, inaktivált vírusos levelekkel, letöltő kódokkal, tehát a probléma nap mint nap jelen van.

Számos olyan eset volt viszont más helyeken, ahol a baj megelőzhető lett volna csak vagy az ottani rendszergazda nemtörődömsége, vagy hozzá nem értése, esetleg a helyben rendszergazdává avanzsált leghozzáértőbb felhasználó nem volt a helyzet magaslatán. Találkoztunk olyan esettel, ahol a tűzfalként funkcionáló router volt úgy beállítva, hogy gyakorlatilag 0-tól 6000-ig minden portot beengedett a szerver irányába, ez a Wannacry esetében gyakorlatilag egy üres kapuban a gólvonalon pattogó labdával ér fel, hogy egy sport hasonlattal éljek. Ha bemegy vége mindennek, és ha nem volt vagy nem működik, de akár ha működik is a mentés akkor is könnyen megsemmisülhet minden ott tárolt adat. A frissítések telepítése a másik tipikusan olyan feladat, ami egy nagyon hálátlan munka. A felhasználóknak csak a nyűg van vele, ha a gépe nem hagyja dolgozni, hibákat dob fel néha, vagy akár bele is sérül egy-egy hibás Windows frissítésbe, de a mostani példa is mutatja, hogy a rendszergazdának sajnos ez is feladata kell legyen, hiába lesz ettől csak ellenség a felhasználói szemében. Bár több munkával jár, a folyamatosan és rendszeresen adagolt frissítések megóvhatnak egy céget az ilyen veszélyektől, miközben a leállások, esetleges frissítésből eredő hibák is redukálhatóak így. Nem szabad tehát fél vállról venni a dolgot és törődni kell ezzel is. A szerverek esetében ez különösen fontos, de nem kevésbé a kliens gépeken is.

Aztán akadtak olyan egészen tehetséges rendszergazda kollégák is, akiknek sikerült azt is megmagyaráznia, hogy nem volt mit tenni, egy zsarolóvírus az sajnos ilyen és lehet az adatokat, több évnyi nyilvántartást újraírni. Egy Wannacry fertőzés esetében még elképzelhető olyan forgatókönyv is, ahol félig-meddig ez a megállapítás helytálló, mert nem feltétlen az informatikus hibájából következik be (a protokoll hibáról tényleg nem tehet senki), ugyanakkor most éppen azokat a pillanatokat éljük amikor egy valamire való rendszergazdának gőzerővel dolgoznia kell a védelem megerősítésén. Ha megkérdezi a kollégát mit tett meg eddig az adatvesztés megakadályozására akkor ezeknek a címszavaknak feltétlen szerepelnie kell a válaszban: 1. Windows-ok frissítése (szerverek és kliensek is) és/vagy a kritikus frissítések ellenőrzése, 2. Mentési rendszer ellenőrzése, szükség esetén külön mentések készítése, 3. A problémás portok ellenőrzése a tűzfalon, ne legyen olyan irányból elérhető, ahonnan nem szükséges azt elérni (főleg az internet irányából ne), 4. Vírusvédelem ellenőrzése, működik-e, frissít-e, 5. Spamszűrés, bejövő levelek szűrése vírusirtóval, amennyiben lehetséges.

A probléma szélesebb körű publikálásával egy időben, szombaton az összes általunk kezelt szervert egyenként átnéztük, ahol szükséges volt telepítettük a frissítést és ellenőriztük a vírusvédelmet és a mentéseket, a tűzfalainkon pedig a problémás portok garantáltan nincsenek az internet irányába veszélynek kitéve. Ahol a megvásárolt szoftver ezt lehetővé tette szerveroldali ellenőrzést is végeztünk, hogy esetlegesen vírusos levelek ne érhessék el a szervert (akadtak is fent ilyenek szép számmal a szűrőkön), illetve ahol rendelkezésre állt a Windows verzióból adódóan WSUS rendszer ott hétfő reggeli határidővel kidelegáltuk a kritikus frissítéseket a kliens gépeknek is, ahol erre nem volt lehetőség ott pedig felhívtuk az ügyfél figyelmét a veszélyre és vagy közösen vagy távoli eléréssel telepítettük a gépekre a szükséges frissítést. Ezzel a minimumra csökkent a kockázat a jövőre nézve, innen már a felhasználók tudatosságán múlik minden, hogy egyénileg elindítanak-e egy ilyen vírust vagy sem. Mindenesetre ezekkel az intézkedésekkel a Wannacry veszélyeit egy átlagos zsarolóvírus szintjére tudtuk csökkenteni.

Nagyon sok olyan céggel is találkozunk, akik az első ilyen katasztrófáig úgy érzik minden rendben, esetleg pont annyit ért valaki a cégnél a rendszer üzemeltetéséhez, hogy megnyugodjon ilyen nem fordulhat vele elő, aztán amikor kész a baj akkor keres csak fel minket, hogy vegyük kézbe az irányítást. Persze a kárt akkor már rendszerint nem lehet helyreállítani, de megelőzni a bajt most még nem késő…

http://www.szerver-telepites.hu

http://www.it-rendszergazda-szolgaltatas.hu