Sziasztok!
Arra gondoltam, hogy jó lenne egy olyan hely, ahol megférnének egymás mellett a különféle számítógépes biztonsággal foglalkozó internetes újságcikkek, leírások, tippek és egyebek (általában fordítások). Némelyik a terjedelme miatt egyszerűen nehezen, vagy egyáltalán nem férne be más fórumokba.
Ha mindez elfogadható, elkezdeném a Comodo Leak Test Suite 34 fázisának részletes leírásával, aztán majd meglátjuk.
Üdvözlettel:
Lóri
A Comodo Leak Test Suite értelmezése
(a CLT.EXE mappájában létrejövő CLT.HTML fájl fordítása)
1. RootkitInstallation: MissingDriverLoad
(rootkit telepítés: betöltődés hiányzó eszközvezérlőként)
Tevékenység: megpróbálja olyan eszközvezérlő kulcsát megkeresni a Windows regisztrációs adatbázisában, amihez a megfelelő fájl hiányzik a lemezen. Ha talál ilyet, önmagát másolja a driver helyére, a hiányzó fájl nevén.
Kockázat: a betöltődő rosszindulatú eszközvezérlők a lehető legveszélyesebbek, mivel az operációs rendszer részeként képesek működni, maximális jogosultsággal.
2. RootkitInstallation: LoadAndCallImage
(rootkit telepítés: LoadAndCallImage)
Tevékenység: megpróbál egy eszközvezérlőt betöltő API-t (ki)használni. A módszert általában (de nem kizárólag) a rootkitek fejlesztői alkalmazzák.
Kockázat: a betöltődő rosszindulatú eszközvezérlők a lehető legveszélyesebbek, mivel az operációs rendszer részeként képesek működni, maximális jogosultsággal.
3. RootkitInstallation: DriverSupersede
(rootkit telepítés: eszközvezérlő cseréje)
Tevékenység: megpróbál felülírni egy létező eszközvezérlőt, majd igyekszik önmagát betölteni a vezérlő helyett, annak fájlnevével.
Kockázat: a betöltődő rosszindulatú eszközvezérlők a lehető legveszélyesebbek, mivel az operációs rendszer részeként képesek működni, maximális jogosultsággal.
4. RootkitInstallation: ChangeDrvPath
(rootkit telepítés: elérési út megváltoztatása)
Tevékenység: az SCM-mel (a Service Control Manager, rendszerszolgáltatásokat irányító windows-os segédprogram) megpróbálja megváltoztatni valamelyik létező eszközvezérlő elérési útvonalát.
Kockázat: a betöltődő rosszindulatú eszközvezérlők a lehető legveszélyesebbek, mivel az operációs rendszer részeként képesek működni, maximális jogosultsággal.
5. Invasion: Runner
(behatolás: csempész, de észrevétlen határsértő értelemben)
Tevékenység: igyekszik módosítani (megfertőzni) az alapértelmezett böngésző fájljait és megpróbál csatlakozni az internethez.
Kockázat: gyakori fertőzési módszer, amivel megkerülhető a fájlok épségét (hogy nem változtatta meg senki) nem ellenőrző tűzfalak védelme.
6. Invasion: RawDisk
(behatolás: lemezmanipuláció)
Tevékenység: megpróbál közvetlenül hozzáférni a lemezhez és módosítani a tartalmát.
Kockázat: gyakori fertőzési módszer, ami sok biztonsági rést nyithat, többek közt megfertőzheti a lemez indítószektorát vagy eszközvezérlőket tölthet be.
7. Invasion: PhysicalMemory
(behatolás: fizikai memória)
Tevékenység: megpróbálja közvetlenül elérni és módosítani a fizikai memóriát, annak tartalmát.
Kockázat: a fizikai memória közvetlen elérése sok biztonsági rést nyithat azáltal, hogy megkerüli az operációs rendszer kötelező biztonsági rendszabályait.
8. Invasion: FileDrop
(behatolás: fájl becsempészése)
Tevékenység: megpróbálja becsempészni magát a Windows SYSTEM32 mappájába.
Kockázat: ha egy vírus be tud jutni a SYSTEM32 mappába, ott könnyen megfertőzhet akár létfontosságú rendszerfájlokat is.
9. Invasion: DebugControl
(behatolás: debug irányítása)
Tevékenység: megpróbálja közvetlenül elérni és módosítani a fizikai memóriát, annak tartalmát.
Kockázat: a fizikai memória közvetlen elérése sok biztonsági rést nyithat azáltal, hogy megkerüli az operációs rendszer kötelező biztonsági rendszabályait.
10. Injection: SetWinEventHook
(beinjekciózás: a windows rendszereseményekre ráakasztható “kampó” beiktatása)
Tevékenység: a Windows SetWineventHook hozzáférési API-ja segítségével megpróbál beinjekciózni egy rosszindulatú DLL-t.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
11. Injection: SetWindowsHookEx
(beinjekciózás SetWindowsHookEx-szel)
Tevékenység: a SetWindowsHookEx nevű közönséges windows-os API segítségével próbálja beinjekciózni a rosszindulatú DLL-t.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
12. Injection: SetThreadContext
(beinjekciózás SetThreadContexttel)
Tevékenység: a ProcessInjecttől kicsit eltérő módszerrel próbálja beinjekciózni a rosszindulatú DLL-t.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
13. Injection: Services
(beinjekciózás: szolgáltatások kulcs)
Tevékenység: megpróbálja módosítani a Services (szolgáltatások) kulcsát a Windows regisztrációs adatbázisában, azért, hogy önmagát is szolgáltatásként indíthassa el.
Kockázat: a kártevő a Windows-zal együtt elindítja önmagát is. A kulccsal olyan rootkitet vagy rendszerindító eszközvezérlőt telepíthet, amivel teljesen átveheti az operációs rendszer irányítását.
14. Injection: ProcessInject
(beinjekciózás ProcessInjecttel)
Tevékenység: megpróbál beinjekciózni egy rosszindulatú DLL-t, a kártevőprogramok íróinak egyik leggyakoribb módszerével.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
15. Injection: KnownDlls
(beinjekciózás: ismert Dll-ek)
Tevékenység: mivel ez az egyik legnehezebben észlelhető fertőzési technika, megpróbálja úgy módosítani az operációs rendszer valamelyik objektumát a memóriában, hogy beültethesse magát egy futó, megbízható folyamatba.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
16. Injection: DupHandles
(beinjekciózás kezelők másolásával, meghamisításával)
Tevékenység: úgy próbál hozzáférni egy másik folyamat memóriájához, hogy ellopja egy megbízható folyamat kezelőit.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
17. Injection: CreateRemoteThread
(beinjekciózás: CreateRemoteThread)
Tevékenység: a ProcessInjecttől kicsit eltérő módszerrel próbálja beinjekciózni a rosszindulatú DLL-t.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
18. Injection: APC dll injection
(beinjekciózás: APC DLL-injekció)
Tevékenység: a ProcessInjecttől kicsit eltérő módszerrel próbálja beinjekciózni a rosszindulatú DLL-t.
Kockázat: egy másik futó folyamatba injekciózott DLL vagy programkód a már futó folyamat részeként képes viselkedni, azonos jogosultságokkal. A kártevők gyakran élnek vissza ezzel a módszerrel, hogy önmagukat megbízható folyamatnak álcázzák.
19. Injection: AdvancedProcessTermination
(beinjekciózás: speciális folyamatmegszüntetés)
Tevékenység: megpróbál megszüntetni egy folyamatot az API debugolásával.
Kockázat: a folyamatok meglepetésszerűen leállíthatók.
20. InfoSend: ICMP Test
(infoküldés: ICMP-teszt)
Tevékenység: megpróbál információt küldeni az internetre ICMP-protokollal.
Kockázat: ha a tűzfal nem szűri az ICMP-protokollt, előfordulhat, hogy nem veszi észre az ICMP-adatfolyamban a trójaiakat sem.
21. InfoSend: DNS Test
(infoküldés: DNS-teszt)
Tevékenység: megpróbál információt küldeni az internetre a Windows DNS API-jaival.
Kockázat: a Windows DNS API-jai megbízható folyamatokat használnak a DNS-lekérdezésekhez, így előfordulhat, hogy a tűzfal nem veszi észre a kérések mögött megbúvó valódi folyamatot.
22. Impersonation: OLE automation
(szerepjátszás: OLE-automatizálás)
Tevékenyég: megpróbálja elindítani az Internet Explorert, majd az elindított IE-példányt OLE-automatizálással igyekszik rávenni, hogy adatokat küldjön az internetes szerverre.
Kockázat: a tűzfalak megkerülésével rosszindulatú fájlok tölthetők le.
23. Impersonation: ExplorerAsParent
(szerepjátszás: az Explorer, mint szülőfolyamat)
Tevékenység: megpróbál az explorer.exe fájl segítségével kapcsolódni az internethez.
Kockázat: előfordulhat, hogy a tűzfalak nem veszik észre az internetes kapcsolati kérelem mögött megbúvó valódi programot.
24. Impersonation: DDE
(szerepjátszás: közvetlen adatcsere)
Tevékenység: DDE-vel, azaz közvetlen adatcserével igyekszik módosítani az IE működését, így próbál adatokat eljuttatni az internetes szerverre.
Kockázat: a tűzfalak megkerülhetővé válnak és rosszindulató fájlok tölthetők le a böngésző megbízható folyamata segítségével.
25. Impersonation: Coat
(szerepjátszás: álruha)
Tevékenység: megpróbálja átnevezni magát az alapértelmezett böngésző fájlnevére a memóriában és az internethez próbál kapcsolódni.
Kockázat: a tűzfalak azt hihetik, hogy a kapcsolati kérelem mögött megbúvó valódi folyamat megbízható.
26. Impersonation: BITS
(szerepjátszás: BITS)
Tevékenység: a Windows Background Intelligent Transfer Service (BITS) szolgáltatása segítségével próbál az internetre kapcsolódni.
Kockázat: a tűzfalak megkerülhetők és a Windows megbízható szolgáltatásaival rosszindulatú fájlok tölthetők le.
27. Hijacking: WinlogonNotify
(eltérítés: Windows beléptetési értesítés)
Tevékenység: egy kártevő megpróbálja módosítani a WinlogonNotify regisztrációs adatbázis kulcsot, hogy a beléptetési folyamattal együtt önmagát is elindíthassa.
Kockázat: a kártevő a Windows minden egyes indításával önmagát is automatikusan elindítja. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit. Ugyanezt a kulcsot szokták manipulálni, amikor az operációs rendszer megbízható folyamataiba szándékoznak kártékony DLL-t injekciózni.
28. Hijacking: Userinit
(eltérítés: felhasználó-inicializáló folyamat manipulálása)
Tevékenység: megpróbálja módosítani a regisztrációs adatbázis Userinit kulcsát, hogy átvehesse annak a userinit.exe folyamatnak a szerepét, amelyik a bejelentkezés után a felhasználói adatok inicializálásáért felelős.
Kockázat: a kártevő a Windows minden egyes indításával önmagát is automatikusan elindítja. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit.
29. Hijacking: UIHost
(eltérítés: UIHost kulcs manipulálása)
Tevékenység: megpróbálja módosítani a regisztrációs adatbázis UIHost kulcsát, hogy átvehesse annak a logonui.exe folyamatnak a szerepét, amelyik a bejelentkezés előtt végrehajtódik.
Kockázat: a kártevő a Windows minden egyes indításával önmagát is automatikusan elindítja. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit.
30. Hijacking: SupersedeServiceDll
(eltérítés: a ServiceDll kulcs manipulálása)
Tevékenység: megpróbálja módosítani a regisztrációs adatbázis ServiceDll kulcsát, hogy az operációs rendszer svchost.exe nevű megbízható folyamatával önmagát is elindíthassa.
Kockázat: a kártevő a Windows minden egyes indításával önmagát is automatikusan elindítja. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit. Ugyanezt a kulcsot szokták manipulálni, amikor az operációs rendszer megbízható folyamataiba szándékoznak kártékony DLL-t injekciózni.
31. Hijacking: StartupPrograms
(eltérítés: automatikusan induló rendszerprogramok kulcs manipulálása)
Tevékenység: megpróbálja úgy módosítani a regisztrációs adatbázis StartupPrograms kulcsát, hogy a Windows indulásakor önmagát is elindíthassa.
Kockázat: a kártevő a Windows minden egyes indításával önmagát is automatikusan elindítja. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit.
32. Hijacking: ChangeDebuggerPath
(eltérítés: a debugger elérési útvonal kulcsának manipulációja)
Tevékenység: megpróbálja úgy módosítani a regisztrációs adatbázis Debugger kulcsát, hogy önmagát indíthassa el, amikor egy program végzetes hibával leáll.
Kockázat: a kártevő minden alkalommal automatikusan elindul, amikor egy futó program összeomlik. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit. Ugyanezt a kulcsot szokták manipulálni, amikor az operációs rendszer megbízható folyamataiba szándékoznak kártékony DLL-t injekciózni.
33. Hijacking: AppinitDlls
(eltérítés: a folyamatokat inicializáló DLL-kulcsok manipulálása)
Tevékenység: megpróbálja úgy módosítani a regisztrációs adatbázis AppInitDlls kulcsát, hogy önmagát minden futó folyamatba beinjekciózhassa.
Kockázat: bármelyik program indításakor a kártevő önmagát is elindítja. Az a tény, hogy ez nem olyan közönséges rendszerindítási kulcs, amit az átlagos diagnosztikai segédprogramok vizsgálni szoktak, növeli a kártevő túlélési esélyeit. Ugyanezt a kulcsot szokták manipulálni, amikor az operációs rendszer megbízható folyamataiba szándékoznak kártékony DLL-t injekciózni.
34. Hijacking: ActiveDesktop
(eltérítés: ActiveDesktop manipulálása)
Tevékenység: megpróbálja megváltoztatni a Windows aktív asztalának hátterét.
Kockázat: a beágyazott HTML-fájl adatátvitelre bírhatja rá a megbízható folyamatként aposztrofált explorer.exe-t és bizalmas információkat csempészhet ki a számítógépről az interneten.
A Leak Test Suite letölthető innen (mérete 123 kB):
[i]Forrás:
http://blogs.techrepublic.com.com/security/?p=1955
(Techrebuplic, információbiztonsági webnapló)
—————————————————————————————————————————————————————
[b]IPv6: Jé, ez alapértelmezésben be van kapcsolva![/b]
[i](Eredeti cím: "IPv6: Oops, it's on by default")[/i]
Vajon Ön tudja, hogy számítógépe aktívan használja-e az IPv6 kommunikációt?
Jobb, ha utánanéz, mivel a rosszfiúk alighanem már tudják!
A Microsoft a Vista kiadásától kezdve alapértelmezésben engedélyezte az IPv6 protokollt és ugyanez a trend folytatódott a Windows Server 2008, valamint a Windows 7 kiadásakor is. Az Apple, a Linux és a Solaris legfrissebb kiadásaiban szintén be van kapcsolva az IPv6.
Mielőtt folytatnám, meg kell magyaráznom valamit. Mindannyian tudjuk, hogy az IPv6 fontos dolog. Korábban már én is vettem a bátorságot és számos cikket írtam e témáról, Joe Klein szíves segédletével (aki a Command Information cégnél IPv6-os biztonsági vezető), így ezt a részt kipipálhatom.
[b]De mit nem pipálhatok ki még?[/b]
Nem tudom pontosan, miért, de a számítógépeket manapság úgy helyezik üzembe, hogy az IPv6 enngedélyezve van rajtuk. Szerintem vagy azért alakulhatott így, mert az operációs rendszereket fejlesztő cégek többsége arra számított, hogy mára az IPv6-os hálózatok túlsúlyba kerülnek, vagy mert ha már úgy is ott az IPv6 opció, akkor minek várni vele?
Azt is tudom, hogy van olyan Microsoft szolgáltatás, ami az IPv6-ra épül: a Windows Meeting Space. Peer-to-peer (egyenrangú) hálózati keretrendszert használ és az IPv6 segítségével automatikusan építi fel az ad hoc (alkalmi, rögtönzött) hálózatokat.
[b]Mekkora számról lehet szó?[/b]
A manapság IPv6-ot futtató PC-k száma elképesztő. Carolyn Duffy Marsan egyik NetworkWorldben megjelent cikkében így idézte Joe Kleint:
“Körülbelül 300 millió rendszer lehet a világban, amelyiken az IPv6 alapértelmezés szerint be van kapcsolva. Ez óriási kockázatnak tekinthető.”
Azért arra kíváncsi lennék, ebből a 300 millióból hány felhasználó veszi észre, hogy IPv6-ot használ vagy egyáltalán tudja-e, hogy ez mit jelent?
[b]Mik a veszélyek?[/b]
Egyik, szintén e témát feszegető párhuzamos cikkében Marsan szakértőket kérdezett arról, mi a legvitathatóbb árnyoldala annak a "duplafenekű" megoldásnak, ahogyan most ugyanazok a számítógépek egyszerre használják az IPv6 és az IPv4 protokollt is? Ezt válaszolták:
* [b]Kártékony IPv6 adatforgalom:[/b] a támadók rájöttek, hogy a legtöbb hálózati rendszergazda vagy nem tudja, vagy nem akarja monitorozni az IPv6-os forgalmat, mivel a legtöbb ma létező tűzfal, IDS (Intrusion Detection System, azaz behatolást észlelő rendszer) és hálózatkezelő eszköz nem képes felügyelni az IPv6-os forgalmazást. Ebből következik, hogy a támadók képesek rosszindulatú adatforgalmat lebonyolítani bármelyik IPv6-ot használó számítógéppel, mert az adatok átjuthatnak az ilyen rendszereken.
* [b]IPv6 tunneling (protokollbújtatás, alagúttechnika):[/b] az olyan protokollok, mint a Teredo vagy az Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) beburkolják az IPv6 protokoll csomagjait és IPv4-es csomagként küldik el. Az ily módon átalakított csomagok könnyedén átjuthatnak az IPv4-es tűzfalakon és NAT-okon (hálózati címfordítók), mivel így megkerülhetik azokat a körkörös védelmeket, amelyek alapértelmezés szerint elutasítják az IPv6-os csomagokat, ha ilyet észlelnek.
* [b]Rosszindulatú IPv6 eszközök:[/b] mivel az IPv6 önbeállító, a támadók számottevően megnövelhetik hatalmukat az IPv6-os számítógépeken egyszerűen azáltal, hogy olyan eszközöket telepítenek a megtámadott hálózatra, amelyek képesek IPv6-os címeket kiosztani. Tovább súlyosbítja a helyzetet, hogy ezek a kártékony eszközök routerként, azaz útválasztóként is képesek működni. Így, ha a támadónak sikerül átkényszeríteni a teljes adatforgalmat saját eszközein, kénye-kedve szerint vizsgálgathatja, módosíthatja vagy akár el is dobhatja az átmenő csomagokat.
* [b]Beépített ICMP és multicast:[/b] az IPv4-től eltérően az IPv6 ICMP és multicast forgalmazást igényel. Ez a tény gyökeresen más hálózati biztonsági megközelítést igényel majd a rendszergazdáktól. Jelenleg az IPv4 hálózatokon az ICMP és multicast forgalom blokkolása a bevett gyakorlat, ez a módszer azonban többé nem használható és mivel az ICMP és multicast csomagokat bonyolultabb szűrni, ezért ez a rendszergazdáktól is megkövetel majd néhány megfelelő biztonsági intézkedést.
[b]Bekapcsolva hagyjuk-e az IPv6-ot vagy sem?[/b]
Hogy bekapcsolva hagyjuk-e az IPv6 protokollt, az körülbelül olyan világos, mint a vakablak. Az egyértelműen igenlők és ellenzők táborán túl van még számtalan egyéni álláspont is. Azt hiszem, jobb lesz, ha idézem a szakértők véleményét Marsan cikkéből:
Tim LeMaster, a Juniper szövetségi csoportjának vezető rendszermérnöke szerint:
“Ha valahol még nincsenek felkészülve az IPv6-ra, a legokosabb nem engedélyezni a hálózaton,” mondja LeMaster. “Viszont képtelenség lenne minden IPv6-os forgalmat blokkolni az elkövetkező öt évben. Csak a szükséges intézkedések meghozataláig kell letiltani és amíg ki nem ismerik a veszélyeit.”
Lisa Donnan, aki a Command Information-nél a fejlett műszaki megoldások részleg alelnöke, kissé más véleményen van:
“Nem szoktuk ajánlani az IPv6 forgalom blokkolását, inkább azt tanácsoljuk, hogy tartsanak felülvizsgálatot és derítsék ki, pontosan hány IPv6-os eszközt és programot használnak a hálózaton. Ha folyik IPv6-os forgalom, akkor tervet kell készíteni hozzá, betanító oktatásokat kell tartani és alkalmazni kell a technikát.”
Sheila Frankel, a Nemzeti Szabványügyi és Technológiai Intézet (NIST) számítógépbiztonsági részlegének számítógéptudósa köztes álláspontra helyezkedik:
“A vállalatoknak mindössze azt a minimális szintű IPv6-os szaktudást kell megszerezniük, amivel megvédhetik magukat a támadásoktól. A másik teendőjük az, hogy a külső, tehát a vállalati tűzfalakon kívül eső szervereiken engedélyezniük kell az IPv6-ot, így egyrészt az ilyen hálózati címmel rendelkező ázsiai ügyfeleik is kapcsolódhatnak a szervereikhez, másrészt saját szakembereik megszerezhetik a kellő szaktudást az IPv6 technikában. Ez lenne a folyamat első lépése.”
Frankel így folytatja:
“Az IPv6 közeleg. Struccpolitika helyett érdemesebb szembenézni a problémával és meghozni azokat a szükséges döntéseket, amelyek folytán a lehető legbiztonságosabban használható.”
Amikor olyan számítógépek kezdtek érkezni hozzám, amelyekben az IPv6 be volt kapcsolva, én rögtön kikapcsoltam a protokollt. Alapelvem azt volt, hogy feleslegesen ne adjunk esélyt a támadóknak. Úgy tűnik, a döntésem helyesnek bizonyult, mivel ügyfeleim számítógépei nincsenek kitéve ennek az újfajta visszaélési lehetőségnek.
Ez idő szerint a taktikám legalábbis beválni látszik, bár nem biztos, hogy filozófiám mindenkinél működni fog. A fenti vélemények alapján mindössze annyit állíthatok biztosan, hogy az IPv6-tal elérhető gyorsulás lényeges, valamint azt, hogy cikkem mindenkinek segíthet eldönteni, hogy saját hálózatának, hálózati számítógépeinek melyik megoldás a legmegfelelőbb.
[b]Hogyan lehet letiltani az IPv6-ot?[/b]
Szerencsére az IPv6-ot letiltani elég egyszerű feladat. Itt van néhány link, amelyek alapján bárki elvégezheti a kikapcsolást a különböző operációs rendszereken, ha nagyon akarja:
Az IPv6 letiltása Linuxon (link)
Az IPv6 letiltása Windows Vistában (link)
Az IPv6 letiltása Mac OS X-en (link)
[b]Záró gondolatok[/b]
A téma határozottan kényes és még sok meglepetést tartogat, mint minden új, a gyakorlatban kipróbálatlan technika, és ezt el is tudom fogadni. Azt azonban kevésbé, hogy a biztonság ismét úgy bukkan fel, mint nem elsődleges szempont. Remélem, ez csak egy múló tévedés.
*
[i]A szerzőről:
Michael Kassner 30 éve foglalkozik számítástechnikával. Jelenleg rendszergazda egy nemzetközi vállalatnál és az MKassner Net biztonsági szaktanácsadója.[/i]
Szép munka, gratulálok, remélem hasznos lesz ez a “kis” GYIK sokaknak :). Már várom, mikor az UPnP és egyéb szükségtelen szolgáltatásokról is látunk egy cikket :D!
Üdv Lóri papagáj!
Nagyon köszi az infot számomra hasznosak volt a cikkeid.
Pl: Az IPv6 ot sem tudtam. Sok is volt a behatolási kísérlet amíg engedélyezve volt. Most hogy le van tiltva szinte alig van. Ha van még ilyen cikked vagy fordításod szívesen olvasnám.