About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (38),Facebook (18),privacy (17),egyéb (12),social media (11),itsec (11),social web (10),biztonság (9),mobil (8),Google (6),OSINT (6),jog (6),szellemi tulajdon (6),tudomány (6),magánszféra (6),szájbarágó (5),email (5),webcserkészet (5),molbiol (5),felzárkóztató (5),Nobel-díj (4),big data (4),Gmail (4),kultúra (4),terrorizmus (4),online marketing (4),kriminalisztika (4),plágium (4),webkettő (4),genetika (3),molekuláris biológia (3),pszichológia (3),azelsosprint (3),Android (3),biztonságpolitika (3),nyelvtechnológia (3),magatartástudomány (3),Apple (3),sajtó (3),2015 (3),orvosi-fiziológiai (3),élettudomány (3),gépi tanulás (3),jelszó (3),üzenetküldés (3),CRISPR (3),Onedrive (3),2-FA (3),popszakma (3),konferencia (3),levelezés (3),kriptográfia (3),reklám (3),biztonságtudatosság (3),hype (3),torrent (3),open source intelligence (3),neuropszichológia (2),Whatsapp (2),deep web (2),FUD (2),kulturális evolúció (2),nyílt forrású információszerzés (2),TOR (2),hitelesítés (2),titkosítás (2),Pécs (2),bűnügy (2),tweak (2),facebook (2),SPF (2),DKIM (2),bűnüldözés (2),DDoS (2),bejutas (2),videó (2),Reblog Sprint (2),természetes nyelvfeldolgozás (2),villámokosság (2),Hacktivity (2),Yoshinori Ohsumi (2),reblog (2),cyberbullying (2),arcfelismerés (2),ransomware (2),fiziológia (2),Netacademia (2),webkamera (2),szabad információáramlás (2),P2P (2),Balabit (2),cas9 (2),beszélgetés rögzítése (2),pszeudo-poszt (2),molekuláris genetika (2),bulvár (2),gépház (2),tartalomszolgáltatás (2),jövő (2),bolyai-díj 2015 (2),könyv (2),Tinder (2),öröklődő betegség (2),HR (2),sudo (2),Yandex (2),bug (2),nyelvtudomány (2),meetup (2),Twitter (2),tanulás (2),biológia (2),netkultúra (2),malware (2),IDC (2),social engineering (2),szociálpszichológia (2),kutatás (2),hírszerzés (2),iOS (2),vírus (2),farmakológia (2),pedofília (2),epic fail (2),génterápia (2)

Hogyan működik a világ legerősebb titkosítási eljárása?


Na jó, a címadással csaltam egy kicsit: egyrészt az egyik legerősebb ma ismert és civil használatra megengedett titkosítási eljárásról fogok írni, másrészt a számításelméleti részletekbe egyáltalán nem megyek bele.

A PGP vagy annak egy klónja, megbízható becslések szerint az egész világon a titkosítást alkalmazó kütyük - legyen szó mainframe szerverről vagy filléres mobilról - közt legtöbb helyen alkalmazott titkosítási eljárás. A PGP valójában két titkosítási eljárás, egy asszimmetrikus és valamelyik szimmetrikus módszer alkalmazásaként működik.

Az asszimmetrikus titkosítás gyakorlatilag minden esetben az RSA módszeren alapul, aminek a működését a következő módon szemléltetném, ráadásul már-már tankönyvi nevekkel: Alice szeretne üzenetet küldeni Bobnak, viszont abban az esetben, ha Alice az üzenetet titkosítja, akkor a titkosításhoz szükséges kulcsot is el kellene juttatnia Bobnak, hogy Bob ugyanazzal a kulccsal az üzenetet vissza tudja fejteni. Abban az esetben, ha a titkosításhoz szükséges kulcsot közben elkapják a titkosított üzenettel együtt, a titkosítás semmit sem ér, hiszen vissza tudja fejteni az is, aki elkapta. Ezzel szemben az asszimmetrikus titkosításnál Alice és Bob egyaránt rendelkezik egy kulcspárral: mindkettőjüknek van egy saját, privát kulcsa, amit csak ő ismer és egy publikus kulcsa, amit bárki ismerhet és ismernie is kell, ha titkosított üzenetet szeretne küldeni neki. Ebben az esetben a történet a következő módon néz ki:
1. Alice és Bob odaadják egymásnak a saját publikus kulcsukat [ezt csak egyszer kell megtenniük]
2. Alice titkosított üzenetet küld Bobnak olyan módon, hogy az üzenet titkosításához a saját privát és Bob publikus kulcsát használja, majd elküldi az üzenetet
3. az üzenet megérkezik Bobhoz, majd az üzenet visszafejtését a saját privát kulcsával, valamint Alice publikus kulcsával végzi el

Azaz egyszer sem haladt át a teljes titkosításhoz szükséges kulcs, mégis tudják olvasni az egymásnak küldött üzeneteket, így az 1970-es években a több ezer éves (!!) ún. kulcsmegosztási problémát oldották meg. Hogyan kombinálódik is az asszimmetrikus és szimmetrikus módszer?

A szimmetrikus kulcsú titkosításnál ugyan csak egy kulcs van, ami a titkosítást és a visszafejtést egyaránt végzi, de ez ideális esetben eléggé erős.

Teljes kommunikáció RSA-val titkosítani egyrészt elképesztően számításigényes lenne, másrészt szükségtelen is, ebből adódott az ötlet, hogy a kettőt össze lehetne lőni, így létrehozva egy olyan titkosítási eljárást, ami kellőképpen erős ahhoz, hogy minden ma ismert törési próbálkozásnak ellenálljon. Ennek az ötletnek az alapján valósította meg Phil Zimmermann a PGP-nek nevezett titkosítási eljárást 1991-ben, ami a következőképp működik:

1. Alice tömöríti az üzenetet, hogy a műveleteket kisebb adathalmazon kelljen végrehajtani
2. Alice egy egyszer használatos, akkor generált kulccsal titkosítja az üzenetet egy szimmetrikus módszerrel
3. Alice magához a szimmetrikus titkosításhoz használt kulcsot - amit beágyaz az üzenetbe - titkosítja Bob nyilvános kulcsával, majd elküldi az üzenetet

Bob az üzenet visszafejtésekor a saját privát kulcsával először az asszimmetrikus titkosításhoz használt kulcsot éri el, majd azzal bontja ki a teljes üzenetet.

nem a teljes PGP ábrája! csak az asszimmetrikus titkosításé

Kultúrtörténeti érdekesség, hogy az internet hőskorában az, hogy egy egyszerű otthoni számítógéppel olyan erős titkosított üzenetet lehetett létrehozni, amit még a nagy-nagy hárombetűs szervezetek sem tudnak visszafejteni szuperszámítógépekkel, akkora riadalmat keltett, hogy 1993-ban az USA-ban eljárást kezdeményeztek Phil Zimmermann ellen, viszont lévén, hogy nem lehet perelni valakit csak azért, mert túl hatékony algoritmust hozott létre, a vád a fegyverek exportját szabályozó törvény megsértése volt. Végül az eljárást 1996-ban megszüntették vádemelés nélkül, addigra pedig a PGP már úgyis elterjedt az egész világon.

Még középiskolás koromban gondolkoztam azon, hogy ha ennyire egyszerű és ennyire hatékony egy titkosítási eljárás, akkor miért nem megy át minden elképzelhető felhasználói adat két fél közt, azaz például ha emailt vagy SMS-t küldünk valakinek, az eszköz csak betöltené a címtárból a feladó nyilvános kulcsát és a címzett már meg is nyitná az üzenetet a saját privát kulcsával. A teljes magyarázat bőségesen meghaladná ennek a posztnak a kereteit, a legfontosabb indokok mogyoróhéjban az emailezés példáján keresztül: pont a 90-es évek elején robbantak be az ingyenesen elérhető email szolgáltatók, amik döntően webes felületen működtek és a felhasználóik tudatosság szempontjából egész egyszerűen nem voltak érdekeltek abban, hogy az üzeneteik titkosítva legyenek, a szolgáltatóknak pedig nem volt érdekük plusz munkát róni a saját szervereikre, ezen kívül a privát kulcsokat is biztonságosan tárolni kellett volna valahol, ha szempont, hogy a felhasználó a leveleit bárhonnan meg tudja nézni, ne csak azon a gépen, amin a saját privát kulcsa van. Megjegyzem: ebben az időben még pendrive-ok és hasonlók kanyarban sem voltak, amin lehetett volna tárolni és használni a privát kulcsot.

Ma pedig az ingyenes levelezőszolgáltatók leggyakoribb üzleti modellje az, hogy a levelezésért nem kell fizetni, viszont egy algoritmus megvizsgálja a levélben előforduló kifejezéseket, majd annak alapján sebészi pontossággal helyez el targetált hirdetéseket a levél szövege melletti oldallécben. Dollármilliárdos piacról van szó. Ha az üzenet titkosított, természetesen a hirdetés targetálása lehetetlen. A Gmailnek például nyilván veszteséges, de nem tiltja, hogy olyan üzenetek továbbítására használják a felhasználók a fiókjukat, amik teljesen elemezhetetlenek az elemzőmotorjaik számára, ez azonban a felhasználóknak csak nagyon kis részét érinti.

Elméletileg megoldható, hogy egy webes levelezőrendszerben PGP-t alkalmazzanak, ez azonban rendkívüli kockázatot rejt magában, hiszen ha valamilyen módon a privát kulcsokat ellopják, az összes felhasználó titkosított levelezése olvasható lesz, ráadásul új kulcsot kellene mindegyiküknek generálnia. Valójában a publikus levelezőrendszerek közt egyetlen normális kivétel van, a Hushmail, ami a privát kulcsok tárolását saját maga oldja meg, ez a kulcs egyébként le is tölthető.

De mit tegyünk, ha saját magunk akarunk olyan titkosított leveleket küldeni és fogadni, amit aztán tényleg nem olvas se ember, se isten, hacsak nem szerezte meg a privát kulcsunkat? Természetesen több konkrét megvalósítás is van, ezek közül az egyik legelterjedtebb kombót mutatom be, ami működik Windowsban, OSX-en és linuxokon is.

Először is a levelezőszolgáltatónknál engedélyezzük az IMAP4/POP3-letöltést - annyira alap szolgáltatás, hogy ha nem lenne lehetséges, időszerű szolgáltatót váltani - majd telepítsünk fel egy levelezőklienst, például a Thunderbirdöt. Ezt követően szükség lesz egy PGP motorra, amiből többféle is létezik, a legelterjedtebb a Gnu Project által feljesztett GnuPG, ami Windowshoz a http://www.gpg4win.org/ címről, OSX-hez pedig a https://gpgtools.org címről tölthető le, a linux-júzerek meg úgyis tudják. Ezek után a Thunderbirdbe telepítsük az Enigmail addont, ami meg fogja hívni a motort, amikor titkosításra van szükség.

Ha mindez megvan, indítsuk el a GnuPG részeként települt PGA-t [GnuPG Agent] vagy a Kleopatra-t, ahol már gyerekjáték új kulcspárt generálni, kezelni. A kulcsunk mérete lehet 1024, 2048, 3072 és 4096 bites is, viszont erősen ajánlott alapértelmezés szerinti 2048 bites kulcsot generálni, mivel más PGP-szoftverek ezzel garantáltan kompatibilisek, ideértve például mobiltelefonok esetén például Android platformon az APG-t, iPhone-nál használt iPGMailt-t is. Fontos, az is, hogy a kulcs több jellemzője is megváltoztatható, a mérete azonban nem!

Ha a kulcspár készen van, aminek a privát részét egy szerkeszthető jelszó is védi, készítsünk róla másolatot, a publikus kulcsot pedig küldjük át annak, akinek szeretnénk GPG-zet levelet küldeni ill. kérjük el az ő publikus kulcsát. Természetesen azért, hogy mindez egyszerűbb legyen, szerte a neten vannak óriási "GPG-telefonkönyvek", ahol ki lehet keresni más GPG-kulcsát az email címe, neve és egyéb adatok alapján, így a publikus kulcsok betölthetők a saját helyi kulcstárunkba illetve mi is feltölthetjük a sajátunkat. Ha egy nagy GPG-adatbázisba feltöltöttük a publikus kulcsunkat, a többibe már nem szükséges, hiszen ezek szinkronban vannak egymással, Magyarországon ilyen például a http://keys.niif.hu/

Amint mindez kész, írjuk meg a titkosítani kívánt levelet, majd küldéskor üssük be a privát kulcsunkhoz tartozó jelszavunkat, az Enigmail pedig a címzett alapján tudni fogja, hogy kinek a publikus kulcsát kell használnia az üzenet titkosításához a kulcstárunkból és a levelet el is küldtük.

Ami még hatalmas előnye a megoldásnak, hogy ha a levelet digitálisan alá is írtuk, az megmásíthatatlanul bizonyítja, hogy a levelet valóban mi írtuk, akkor, azzal a tartalommal, közben nem írt át benne senki semmit és mivel egy GPG-kulcshoz több email cím is hozzárendelhető, ha az email címünk megváltozik, de a leveleinket továbbra is aláirkáljuk, az igazolja a címzett oldalán, hogy tényleg mi vagyunk csak más címmel, nem pedig valaki a nevünkben akar levelet írni.

A posztban nem tértem ki rá, hogy természetesen minden normális levelezőklienshez hozzá lehet adni olyan kiegészítőt, ami lehetővé teszi a PGP-zést, csak éppen van, amelyikben iszonyatosan fapados módon működik. Ahogy nem tértem ki a kulcspár finomhangolási lehetőségeire sem [érvényességi idő, kulcs értvénytelenítésének lehetősége].

Amit viszont nagyon fontos megjegyeznem, hogy a szimmetrikus- és asszimmetrikus titkosítást természetesen nem csak emailek titkosításánál használják, hanem ez a lelke például az SSL/TSL-titkosításnak is, aminek a nyomát nap, mint nap látunk a böngészőben szinte minden, önmagára valamit is adó webszolgáltatásnál, kis lakatként a böngészőben a címsor elején. Ott az egyszer használatos kulcs ismétcsak nálunk van, de a böngésző belügye, hogy azt hogyan kezeli, míg a publikus kulcs a szervernél, ami éppen kiszolgálja a webhelyet. A titkosítás eléggé világos ok miatt sokkal kisebb, mint 2048 bites kulccsal dolgozik. De a technika egyre több internetes telefonálást vagy chatelést biztosító szolgáltatásban is ott figyel, nem mellékesen nem mindegyikben, amelyikre a gyártó azt mondja, hogy igen. A ütősebb, jóval erősebb hardveres titkosítást alkalmazó pendriveok titkosításának az alapja ugyanez.

Néhány kapcsolódó téma, amibe most szintén nem mentem bele: az alkalmazott asszimmetrikus módszertől függően bizonyos kulcsok csak titkosításra használhatók, digitális aláírásra viszont nem valamint az, hogy a titkosítás szigorúan számításelméleti szempontból feltörhetetlen, nem jelenti azt, hogy a gyakorlatban is az: például, ha az egész véletlenül hibásan van leprogramozva vagy az algoritmusnak az a része, ami a kulcspárok generálásához a dög nagy prímszámokat nem teljesen véletlenül választja ki, így a lehetséges privát kulcsokból sokkal kevesebb állítható elő - amiből nemrég orbitális botrány is lett

A GPG-ről egyébként Thunderbird-GunPG-specifikusabban egy behatóbb cikket is írtam néhány napja, amit itt találtok meg

[kollégák figyelmébe: itt ismeretterjesztő cikkről van szó, ennek megfelelően lett megírva, az egyszerűsítések és az érthetőség kedvéért alkalmazott kevésbé precíz megfogalmazás, a PGP és GPG itt-ott szinonimaként való használata az érthetőséget hivatott szolgálni] A magyarázó ábra forrása: Wikipedia. 

1 Tovább

Facebook-fiók megszerzése kamu ismerősökön keresztül


Többször emlegettem már, hogy ha egy világméretű szolgáltatásról van szó, arról hajlamosak vagyunk azt hinni, hogy a rajta működő fiókunk teljes biztonságban van, főleg a relatíve egyszerű, azaz invazív törési technikákat nem igénylő módszerekkel szemben védett. Nos, nem. Már-már könyvet tudnék írni, hogy ilyen-olyan közösségi szolgáltatásokban hogyan lehet idegen fiókot megszerezni vagy eltéríteni, a felhozatalban pedig a Facebook előkelő helyen lenne. A módszerek többségéhez minimális programozási tudás szükséges vagy még annyi se, én most a legfrissebbet mutatom be.

A Facebook egy nem túl régen bevezetett újításaként a https://www.facebook.com/settings?tab=security&section=trusted_friends&view tabon meg lehet jelölni olyan ismerősöket, akiknek a segítségét lehet kérni abban az esetben, ha a fiókunk hozzáférhetetlenné válik, azaz nem tudunk belépni, de nem küldhető jelszó-helyreállító token sem emailen, sem mobilon SMS-ben, nem állítottunk be biztonsági kérdést és még egy okostelefon sincs hozzárendelve a fiókhoz. Ilyenkor van rá lehetőség, hogy a 3-5 kijelöl megbízható ismerősnek a Facebook küldjön egy-egy kódocskát, amiket hozzánk eljuttatva, majd aokat általunk beütve a Facebook fiók ismét elérhetővé válik. A nem kis probléma pedig az, hogy a Trusted contacts beállítása nem kötelező és a felhasználók többségénél nincs is bekapcsolva, a most bemutatásra kerülő account-hijacking erre alapul.

Tételezzük fel, hogy valaki fel akarja nyomni az accountomat, így a Facebook nyitóoldalán a "Forgot your password?" pontot választja. Itt kereshető az áldozat a "helyreállításra szoruló" fiók egyedi azonosítója, rövid, ún. user-friendly neve, teljes neve, email címe(i), telefonszáma(i) alapján egyaránt. Ekkor valami ilyesmi tárul a szemünk elé:

facebook feltörés

Mivel itt lehetőség van azt az opciót választani, hogy a megadott elérhetőségek egyikéhez sincs hozzáférésünk, ezt követően a Facebook bekér egy tetszőleges email címet, amin felveheti velünk a kapcsolatot szükség esetén.

Továbblépve ezután választhatjuk azt a lehetőséget, hogy a barátainktól kérünk segítséget a fiók visszaállításához és itt jön a csavar: abban az esetben, ha korábban az áldozat nem jelölt ki megbízható kontaktokat az előbb emlegetett Trusted contacts tabon, az összes ismerős közül, teljesen tetszőlegesen lehet választani, hogy kitől kérünk segítséget. Jól ismert, hogy az átlag felhasználó igencsak tapintatos tud lenni, ha ismerősnek jelölik, gyakorlatilag visszajelöl boldogot-boldogtalant, így az sem ritka, hogy egy fogát csikorgató ex vagy éppen egy kirúgott beosztott van fent az ismerősök közt kamu néven, ezen kívül minden további nélkül fent lehet néhány kémkedő - szakargóban stalker - kamu felhasználó is, amit pont a támadó tett oda mondjuk több hónap alatt, hogy ne legyen túl feltűnő. Ha tehát legalább három olyan kamu felhasználót vett fel az áldozat, amit maga a támadó hozott létre és vetette fel velük magát ismerősnek az áldozattal korábban, nem nehéz megjósolni a következményt. Ezen a ponton ha a támadó kijelöli a saját három alvó ügynökét, akiknek a postafiókjába landol a három helyreállításhoz szükséges tokenkódocska és amint a támadó azokat megadja, már meg is szerezte az áldozat Facebook-fiókját.

facebook hacking

Egyedüli részmegoldásként azzal lehet csökkenteni a kockázatot, ha kijelölünk megbízható kontaktokat, így egy ilyen típusú támadás esetén a támadó nem tud tetszőlegesen választani az ismerőseink közül, amik némelyike esetleg mind hozzá tartozik.

Megj.1: a leírás messze nem tér ki minden leetséges scenariora, ezért nem biztos, hogy mindenkinél működik
Megj 2: a Facebook azért nem teljesen hülye, ha valaki amatőr módon, azaz anonimizálási technikák nélkül fog neki egy ilyennek, a Facebook millió meg egy dolog alapján azonosíthatja és végleg kirúghatja a támadót az összes accountjával együtt, ideértve a valódit is. Azaz ne próbáld ki otthon.

9 Tovább

WinXP hardening egyszerűen


Most, hogy megszűnt a Windows XP hivatalos támogatása, sejthető volt, hogy nem kevesen alaposan meg fogják lovagolni ezt a témát vagy azért, hogy a felhasználói tájékozatlanságra apellálva ezzel is keressenek vagy éppenséggel azért, mert zugfirkászként csak azért is, ők is akarnak mondani valamit ebben az XP-hardening témában valami okosat, ezen cikkek többsége viszont olyan, hogy írhatták volna akár a Windows 2000 korában is, akkora arcpirító banalitásokat tartalmaz.

Ami világos, hogy a felhasználók tényleg nem látják a kockázatot ebben az egészben, az armageddon pedig még várat magára egy picit és persze nem úgy fog bekövetkezni, ahogy azt az egység sugarú felhasználó elképzeli: nem gonosz hekkerek kukáznak össze több hegynyi mennyiségű információt sérülékeny rendszerekről [azt eddig is megtehették és teszik is, viszont általában nem az oprendszer a bűnös, hanem a biztonságtudatosság hiánya], hanem sérülékeny gépeket felhasználják majd botnet hálózat smurfjeként DDoS támadásokhoz vagy spammeléshez, aztán emberünk csak leshet, amikor a postafiókjából küldött leveleket kutya sem kapja meg, mert még a rendszeres levelezőpartnereinél is spambe landolnak a levelei, lévén, hogy blacklisten lesz az IP-címe, mailcíme vagy bármi más miatt, mivel a tudta nélkül, ő gépén keresztül küldtek jó sok viagrareklámot Fülöp-szigeteki látogatók. A kockázat elsősorban azokat a felhasználókat érinti, akiknél a dinamikus IP viszonylag ritkán változik, márpedig ez a gyakoribb: UPC.

Nos, a felhasználók többsége nyilván nem is eléggé involvált, másrészt nem is eléggé ért hozzá, hogy a windowsos rendszerét - legyen az XP vagy újabb - valóban biztonságossá tegye az általános user awarenesstől kezdve a fölösleges szolgáltatások kikapcsolásán és a kétes eredetű szoftverek legyilkolásán át a registry fúrás-faragásig. Ebből alighanem lejön, hogy mindezt külön tudomány, nyilván nem megyek bele, inkább kiemelek egy könnyen kivitelezhető részmegoldást, amivel nagyban fokozható akár egy XP-s gép biztonsága is.

Azok az idők már rég elmúltak, amikor a komplett antivirus-personal firewall-host intrusion detection megoldásokért egy rakás pénzt kellett volna fizetni, mi több, a legpatinásabb független szervezet, az AV-comparatives elemzése szerint a világ 10 leghatékonyabb antivírus- és személyi tűzfal terméke közt jobban teljesítenek, amik nem-fizetősek, hanem például donation vagy freemium alapon működnek, azaz nem kell közvetlenül fizetni értük. Személyes kedvenc wines környezetben a Comodo Internet Security terméke, amit az is kényelmesen tud telepíteni és használni, akit végképp nem érdekel ez az egész, tényleg csak használni akarja a gépet, viszont az is imádni fogja, aki megrögzött geekként imád minden apró részletet saját maga beállítani.

A Comodo Internet Security tartalmazza az antivírus motort, a legalább ennyire fontos HIPS-et és a persze személyi tűzfalat, amik mindegyike egészen gyorsan tanul, ha arról van szó, hogy a felhasználói szokásokat figyelve eléri, hogy minimálisak legyen a fals pozitív riasztások száma, viszont a disznóságokat szinte 100%-os hatékonysággal szűrje. A CIS free és CIS pro [előfizetéses] változata közt mindössze annyi a különbség, hogy az utóbbihoz jár terméktámogatás, azaz a végképp hozzá nem értő felhasználó telefonon, chaten és egyéb-egyéb módon zargathatja a CIS támogatási csoportját. A másik forrás, ami miatt a CIS fejlesztésére nem keveset tudnak költeni, mégis ingyenesen tudják adni, nem más, minthogy a Comodo bevétele döntő részt enterprise level megoldások értékesítéséből származik, viszont egy nagyon erős, felhasználóknak szánt antivírus-terméknek nagyon erős márkaépítő ereje van.

Ami ezen poszt megírásának alapötletét adta, a Comodo szintén ingyenes törésteszt-szoftvere. Miről is van szó? Az online tűzfaltesztekkel ellentétben itt arról kapunk nagyon jó képet, hogy milyen eséllyel kerül fel egy malware a gépünkre és ha már felkerült, akkor milyen károkat képes okozni. A szoftver letöltése után 300-400 tipikus windowsos sebezhetőséget vizsgál végig a progi, amik jórésze sokaknak nem mond semmit, viszont igen hasznos lehet, ha megmutatod valakinek, aki ért is hozzá. A tesztet erősen ajánlott lefuttatni frissítetlen windowsos rendszeren, frissített, de biztonsági csomag nélküli rendszeren és tetszőleges biztonsági megoldást használó rendszeren egyaránt. Ideális esetben a 400 test case átvizsgálása során a tűzfalprogramod és az AV-d - legyen az bármelyik - többször is sipákol, miszerint valószínűleg valami disznóság folyik a háttérben, ami biztos, hogy wines rendszer, ami mind a 400 akadályt csont nélkül veszi, ritka, mint a fehér holló, a saját, Win7-es gépemet Windows Server tapasztalatok alapján, több száz alapbeállítás megváltoztatása után sikerült 100%-ra biztosítani a teszt alapján.

9 Tovább

Meanwhile in Russia: LiveJournal


Aki lemaradt volna: LiveJournal-ékat ismét alaposan DDoS-olták :(

0 Tovább
5678910
»