Month: July 2011

RUP4 újra

Valószínűleg senkinek nem mondok vele újat, de azért csak jobb, ha le van írva.

Röviden a sztori.

A közelmúltban kijött az Exchange 2010 Rollup Pack 4. Aztán pár nappal később pánikszerűen visszavonták. Az történt ugyanis, hogy bizonyos esetekben a move furán viselkedett: a subfolderek tartalmát nem másolta át az új helyre, ellenben a régiről törölte. Eléggé ciki.

Most jött a hír, hogy átnézték, kijavították és immár itt az új, hibátlan RUP4, emellett pedig igyekeztek meg is magyarázni, hogyan történhetett ez meg.

Mathematics by Exchange: Unlimited = 5MB

Exchange migráció közepén vagyunk. Lassan gyűlnek a fejemben a cikkek, amiket meg kellene írni. Íme az első:
Egy felhasználó jelezte, hogy az OWA-ból nem tud 5MB-nál nagyobb levelet csatolni.

Ezen elcsodálkoztam. Sehol sem állítottam be 5MB korlátot a rendszerben. A ki- és bejáratokon 20MB limit van.  A felhasználóknál nem állítottam semmit így a szervezet beállításait öröklik, a globális beállításokat pedig kivettem (hogy miért, arról majd egy másik cikkben írok), tehát itt “Unlimited” a beállítás.
Megnéztem az Outlookban. Itt tudok nagyobb csatolmányt felvenni, tehát kell lennie valami külön az OWA-ra vonatkozó beállításnak. Elkezdtem keresgélni és találtam is valamit:

http://technet.microsoft.com/en-us/library/aa996835.aspx

Itt lehet állítani a limitet, de itt a gyári beállítás (és az én rendszeremben is) 35MB. Ez tehát nem okozhatja a problémát. Némi keresgélés után telefon Józsinak, hátha ő tud valamit. Tőle annyi infót kaptam, hogy az egyik kollégája belefutott már ebbe, volt is rá megoldás, de nincs meg, hogy mi.

Keresgélek tovább. Ráakadtam erre a cikkre:

http://www.exchange-genie.com/2009/09/when-unlimited-is-not-unlimited/

Szóval érdekes az Exchange matematika.

Ezek után a globális beállításokon beállítottam valami óriási méretet. Ez még önmagában nem oldotta meg a dolgot, de egy IIS újraindítás segített.

Mondd meg a Ferinek, hogy szóljon a Janinak

Ügyfél haladt a korral. A saját alkalmazásai korábban MAPI-n keresztül érték el az alkalmazásokhoz tartozó Exchange postafiókokat. A felhasználók autentikálták magukat az alkalmazások indulása után, aztán vagy volt joguk az egyes funkciók postafiókjaihoz, vagy sem – attól függően, milyen jogosultságok voltak beállítva közvetlenül a postafiókon.

Mint írtam, haladtak a korral. Az alkalmazások új verziójában úgy döntöttek, hogy szakítanak a MAPI-val, helyette inkább webes protokollokon keresztül érik el a postafiókokat.
Első ránézésre nincs is nagy gond, megkapták a mailbox szerver helyett a CAS szerver nevét, aztán hajrá.
Nem sikerült. Még az atyaúristen jogosultsággal bíró fejlesztők sem tudtak kapcsolódni egy postafiókhoz sem. Azt a választ kapták, hogy nincsenek megszemélyesítve.

Hmm? Ez meg mi?

A CAS szerver önérzete. Ugyanis most nem közvetlenül fordulunk a mailbox szerverhez, hanem egy CAS (azaz web) szerveren futó webes szolgáltatáson (EWS) keresztül. Márpedig ahhoz, hogy ez az egész működjön, az kell, hogy a webes szolgáltatás megszemélyesítse a hozzáforduló személyt a mailbox szerveren. (Megjegyzem, a Free/Busy információk webes lekérdezése is hasonlóképpen működik.)

A megszemélyesítésben két jogosultság is keresztbetehet:

  • ms-Exch-EPI-Impersonation: Ez egy, a CAS szerverekre vonatkozó jogosultság. Azt lehet vele szabályozni, hogy a kérelmező egyáltalán bekerülhessen a megszemélyesítés bizniszbe. Ha ez a jogosultság tiltott, akkor az illetőt már a CAS szerver elhajtja.
  • ms-Exch-EPI-May-Impersonate: Ez a jogosultság a mailbox szerveren értelmezendő. Szintjei nincsenek (azt továbbra is a postafiókon szabályozzuk), itt csak az dől el, hogy a kérelmezőt megszemélyesítő webes szolgáltatás hozzáfér-e valaki nevében a postafiókhoz, vagy sem.

Mondanom sem kell, ebből az egészből semmi nem volt beállítva. Nyilván el lettek hajtva az alkalmazásokon keresztül érkezők.

Szerencsére a megoldás technikailag nem volt túl bonyolult. Kérni kellett egy listát arról, hogy milyen postafiókokhoz milyen felhasználóknak kell hozzáférniük. Mindegyik postafiókhoz készült egy biztonsági csoport, benne a megadott felhasználókkal, illetve az összes biztonsági csoportot betettem egy CAS-Impersonate biztonsági csoportba.

Első lépésben a CAS-Impersonate csoportnak megadtam a CAS szerveren a megszemélyesítési jogot.

Add-ADPermission -Identity <CAS_server_name> -User <CAS-Impersonate> -extendedRight ms-Exch-EPI-Impersonation

A következő lépésben postafiókonként (PFname) lefutattam a következő parancsot:

Add-ADPermission -Identity <PFname> -User <PfGroup> -extendedRight ms-Exch-EPI-May-Impersonate

Ugye, milyen egyszerű?

Hát, nem.

Az ördög megint a részletekben vigyorog. Az Add-ADPermission ugyanis roppant kényes ízlésű jószág, semmilyen más azonosító paramétert nem fogad el, csak az objektum distinguished name értékét. Mindenhol. Az első parancs sikeres végrehajtásához le kell vadásznod (adsiedit) mind a CAS szerver dn értékét, mind a CAS-Impersonate csoport dn értékét. A második parancs még durvább. Így, ahogy fentebb látod, nem is működik.

Add-ADPermission -Identity <Username> -User <PfGroup> -extendedRight ms-Exch-EPI-May-Impersonate

Ahol az <Username> egy konkrét felhasználói objektum dn értéke, a <PfGroup> pedig az általam a postafiókhoz kreált csoport dn értéke. Ebben az esetben a csoport pontosan azt a szintű jogosultságot kapja meg a postafiókra a megszemélyesítésen keresztül, mely az <Username> felhasználónak is van.

Az eljárásról van cikk, itt találod.

Miszter X és a fejléc tűzfal

Egyszer már piszkálgattam a receive konnektorokat, csakhogy ezek olyanok, hogy nem lehet sokáig piszkálatlanul hagyni őket.

De most egy kicsit más perspektívából szeretnék foglalkozni velük, sőt, nem is csak velük. Bemelegítésképpen nézzük meg ezt az ábrát.

From Segédlet

Szép ábra, sokat szoktam nézegetni. (Az eredeti, poszter méretben itt található.) De nem csak szép, hasznos is. (Tipikus háttérkép a desktopra.)
Nos, ha eleget nézegetjük, feltűnhet, hogy van egy elem, mely többször is szerepel rajta. Narancssárga téglalap és az van beleírva, hogy header firewall. Ahhoz képest, hogy mennyiszer szerepel, nem mondhatni, hogy túlzottan benne lenne a köztudatban.

Na, ezen szeretnék most javítani.

Első lépésben vizsgáljuk meg, mi is az a header, amit tűzfalazni kell. Nagy vonalakban az email (és most csak a belső részéről beszélek, a boríték jelen cikkben nem játszik) két részből áll: fejlécből és tartalomból. A fejlécen belül pedig megkülönböztetünk szabványos mezőket és nem szabványos (vagy ronda szóval élve kvázi-szabványos) mezőket. A szabványosakat RFC írja le, a nem szabványosakról nem ír semmit az RFC (azért nem szabványosak), de elterjedt, hogy az X betűvel kezdődő fejlécmezők gyakorlatilag bármiből állhatnak, bármit jelenthetnek. Azaz ezek a mezők gyártóspecifikusak: egy konkrét gyártó smtp szervere érteni fogja, mit akar üzenni neki egy másik, hasonló szerver, a többi smtp szerver meg nem foglalkozik ezekkel a mezőkkel.
A valóságban itt is lezajlott egy evolúció, néhány X-mező annyira elterjedt, hogy ma már a kitalálójától eltérő gyártók is használják.

Mire jók ezek a mezők? Rengeteg mindenre. A feladó smtp szerver belerak egy csomó információt, melyeket utána a többi smtp szerver is fel tud használni. Ide kerülhet bele, hogy a levél mikor lépett be az Exchange birodalomba, milyen autentikációs módszerrel jutott be, milyen transport rule-ok gyötörték meg a levelet, sima levél vagy journaling… és egy csomó egyéb dolog. Akár magunknak is gyárthatunk X-mezőket. (Igaz, ez a cikk még eventsink-kel dolgozik, de ügynökkel sem lehet sokkal bonyolultabb.) X-mezőbe kerül bele az például, hogy a levelet mennyire érezte szpemnek egy korábbi smtp szerver (Spam Confidence Level, SCL), illetve az is, hogy már átment egy vizsgálaton és ne vizsgálják többet.

Hoppá.

Bejelzett a vészcsengő? Egy szpemmer számára mi sem lenne egyszerűbb, mint rögtön az elején belerakni a levelekbe egy X-mezőt, miszerint ezt a levelet már ne vizsgálják, oszt jónapot.

Na, itt lép be a képbe a header firewall. Ez ugyanis azt csinálja, hogy – beállítástól függően – kipucolja akár az Exchange által használt X-mezőket, akár az egyéb fejlécmezőket a levelekből. Így bejövő levél esetében nem hiszünk el semmit a többi smtp szervernek, kimenő levél esetén nem adunk ki olyan információt, mely segíthet feltérképezni a belső rendszerünket.

Ennyit a bevezetésről, jöhet a vadulás.

Hogyan tudjuk aktivizálni a header firewallt? Hát, úgy, hogy letiltjuk. Gyárilag ugyanis általában működik. De nagyon nem mindegy, hogy kifelé megy a levél, vagy befelé jön, illetve a feladó smtp szerver milyen jogosultságokkal bír a konkrét (receive/send) konnektoron. Érzem, hogy ebből nehéz lesz érthetően kijönnöm, inkább írok egy példát. Egy konkrét receive konnektoron engedélyezem az Ms-Exch-Accept-Headers-Organization jogosultságot mondjuk az ExchangeServers jogosultsági csoportnak. Ebben az esetben, ha egy levél ezen a receive konnektoron keresztül jött be és a sessiont kezdeményező akárki tagja az ExchangeServers jogosultsági csoportnak, akkor a header firewall kussol, legalábbis az organizáció szintű X-mezőkkel kapcsolatban. (Az Exchange X-mezőknek két nagy csoportja van, az organizáció szintűek és az erdő szintűek. Az előző jogosultságnak az erdő szintű X-mezőkre vonatkozó párja az Ms-Exch-Accept-Headers-Forest jogosultság.) Ha a sessiont kezdeményező nem tagja az ExchangeServers permission groupnak, azaz tiltva van számára az a bizonyos accept-headers jogosultság, és a levél ezen a receive konnektoron keresztül jön be, akkor a header firewall már ugrik és gyapálja is ki az organizáció szintű X-mezőket. Értelemszerűen a send konnektorokkal is hasonlóan tudunk elbánni.

Szóval, jogosultság és jogosultsági csoportok. Emlékszünk?

From Segédlet

Látható, hogy gyárilag létezik néhány előre definiált jogosultsági csoport (permission group). Hogy még durvább legyen a helyzet, létezik néhány előre definiált receive konnektor tipus is.

From Segédlet

Gondolom, senkit nem lep meg, hogy mindegyikhez – tehát jogosultsági csoporthoz is és konnektortipushoz is – eleve be van állítva, hogy működjön a header firewall, vagy sem.

Na, ezt nem kis munka lesz nyomon követni.
Szerencsére annyira nagy sem.

Mind az organizáció, mind az erdő szintű X-mezőket illetően a receive konnektoroknál csak az internal tipusnál és csak az ExchangeServers jogosultsági csoportnál nem működik a header firewall, minden más esetben igen.
Send konnektor esetén némileg bonyolult a helyzet, ott gyárilag nem jogosultsági csoport van hozzárendelve a konnektorhoz, hanem security group. Nagy általánosságban elmondható, hogy ha internal tipusú konnektort gyártottunk, akkor az Exchange szervereket tartalmazó csoportoknál nem működik a header firewall, minden más esetben igen.

Jogos lehet a kérdés, hogy bele tudunk-e ebbe piszkálni? Nos, egy irányba igen. Ha nagyon megerőszakoljuk a rendszert, akkor be tudjuk állítani, hogy az Exchange szerverekre is vonatkozzon a tűzfal.

Azaz összességében elmondható, hogy az Exchange 2010 elég kegyetlenül bánik a saját X-mezőivel: se ki nem engedi, se be nem engedi azokat, de még bent is csak az ExchangeServers jogosultsági csoport élvez mentességet. És ezek közül sem mindegyik. Organizáció, illetve erdő szintű X-mező eleve csak a 2007-es verziótól felfelé létezik, azaz ha korábbi verziójú szerverről jön levél, akkor dolgozik a header firewall (mert vagy nincs benne ilyen X-mező, ha meg van, akkor biztosan sunyi módon került bele), illetve amennyiben korábbi verziójú Exchange szerverre megy a levél, akkor meg azért lép akcióba a header firewall, mert tök felesleges lenne az X-mezőket benne hagyni, a szerver úgysem értené.

Megjegyzem, a levélküldésbe nem csak konnektorokon keresztül kerülhetnek be a levelek. Tessék csak megnézni, a narancssárga téglalapok ott vannak minden kilométerkőnél.

  • Pickup könyvtár: Ide lehet manuálisan leveleket behajigálni. A header firewall működik.
  • Replay könyvtár: Ide kerülnek azok a levelek, melyek egyszer már bent voltak a queue-ban, csak éppen valamiért kikerültek onnan. Ha ez a queue Exchange2010-es volt (az X-Createdby X-mező értéke MSExchange14), akkor a header firewall békén hagyja a levelet, ha nem, akkor rávetődik.
  • Drop könyvtár: A külsős alkalmazások könyvtára, a foreign konnektorok révén ezen keresztül tudnak leveleket küldeni, fogadni. A header firewall aktív.
  • Store driver: A kapcsolat a mailbox adatbázis és az smtp motor között. A kifelé menő levelek esetében a header firewall kivágja az illetékes X-mezőket, a befelé jövő levelek esetében válogat: bizonyos X-mezők repülnek, mások maradhatnak. (Oké, pongyola voltam. Általánosságban elmondható, hogy a szpemekkel kapcsolatos X-mezők maradnak, a többiek nem. Az ugye tiszta, hogy ezeket az infókat csak a mi smtp szerverünk rakhatta bele a levélbe, mert a kintről jövő levelekből az Edge/Hub már korábban kivágta az ilyesmit, már ha léteztek egyáltalán.)
  • Delivery Status Notfication, DSN: A header firewall mindig kigyapálja az X-mezőket a DSN-be ágyazott eredeti levelekből.

Jó. A trükkös szpemekkel elbántunk. (Az SCL is X-mező, Exchange 2010-ben egész pontosan így hivják: X-MS-Exchange-Organization-SCL.) Az X-mezők kaptak egy tockost meg egy kokit, nem mennek kifelé, nem jönnek befelé. De jó-e az nekem, ha pl. egy alkalmazásszerverem az Exchange szerveren keresztül küld ki levelet, és ez az útvonal benne marad a levélben? Nevekkel együtt? Ki tudnám ezt gyapálni?
Ki.
A logika teljesen hasonló az organizáció illetve erdő szintű X-mezőkhöz. Ha egy konnektoron engedélyezve van egy identitás számára a Ms-Exch-Accept-Headers-Routing jogosultság, akkor a routing információk benne maradnak a levél fejlécében. Ha nem, akkor a header firewall kitörli azokat.
Nézzük az alapértelmezéseket. Receive konnektoron a a következő jogosultsági csoportok számára helyből engedélyezve van a jog (azaz tiltva a header firewall): Anonymous, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partner. Valamennyi név a naptárban. (Vessünk egy pillantást a fenti ábrára: csak ezek vannak.) Hogy lehet akkor aktivizálni a header firewallt, hogy mégiscsak rúgja ki a routing információkat? Úgy, hogy Custom konnektort készítünk és nem adunk meg semmilyen jogosultsági csoportot. Vagy meglévő konnektorból töröljük ki az összeset. Vagy az Add-ADPermission paranccsal vesszük el egy-egy csoporttól a konkrét konnektoron a jogot.
A Send konnektorokok esetében nagyjából hasonló a helyzet, alapértelmezésben a routing információk maradnak, de ha akarjuk, akkor a jogosultság tiltásával a header firewall kiszedi azokat. Érdemes megemlíteni itt is az alternatív útvonalakat: a Replay, Drop könyvtárak, illetve az ügynökökön keresztül érkező levelek esetében a header firewall nem bántja a routing információkat. A Pickup könyvtár esetében mindig törlődnek a routing információk. Szintúgy a DSN-be ágyazott levelek esetében. A Store driver a kifelé menő levelek esetében töröl, a befelé jövők esetében nem. (Ez egy kicsit félrevezető lehet. A Store driver a mailbox és a hub transport szerepkör között dolgozik. Azaz ha jön egy levél a mailbox adatbázisból, melyet a kliens mondjuk MAPI-n keresztül rakott össze, annak a routing információit – ha vannak egyáltalán – nem engedjük ki. De a következő lépésben a hub transport szerver belerakja a saját routing információját és az már marad.)

A sok elmélet után jöjjön most egy konkrét példa. Van egy Oracle szerverünk, meg egy csomó alkalmazásunk. A szerveren fut egy smtp szerver is, az alkalmazások azon keresztül leveleznek, illetve a cégből kifelé egy Exchange szerveren keresztül. Hogyan tudjuk megoldani, hogy az internetre ne kerüljenek ki az Oracle szerverre vonatkozó routing információk? Úgy, hogy a szerver kap egy egyedi receive konnektort (csak az ő IP címe szerepel benne), a jogosultsági csoportok közül meg egyet sem adunk meg. Ekkor a konnektoron nem lesz Ms-Exch-Accept-Headers-Routing jogosultság, amit a header firewall úgy értelmez, hogy tiltva van – azaz törli az addigi routing információkat.
Aha. Viszont rögtön belefutunk abba, hogy ez egy open relay tipusú konnektor (igaz, csak egy IP címre), amelyhez Externally Secured autentikáció kell. Ez viszont kiköveteli az ExchangeServers jogosultsági csoportot. Megoldás: az Add-ADPermission paranccsal csak ezen a konnektoron deny-re állítjuk az ExchangeServers permission group jogosultságát az Ms-Exch-Accept-Headers-Routing elemi jognál.

Ezzel tulajdonképpen be is fejeződhetne a cikk. Beszéltünk 3 jogosultságról (Ms-Exch-Accept-Headers-Organization, Ms-Exch-Accept-Headers-Forest, Ms-Exch-Accept-Headers-Routing), arról, hogy mi történik, ha ezeket a jogosultságokat elvesszük, illetve arról, hogy mik a gyári beállítások. Úgy gondolom, hogy hasznos lehet a másik oldalról is ránézni az összerendelésekre: milyen jogosultságokkal rendelkeznek beépítetten az egyes jogosultsági csoportok?

Anonymous (Anonymous user account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
– Ms-Exch-Accept-Headers-Routing

ExchangeUsers (Authenticated user accounts)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-Accept-Headers-Routing

ExchangeServers (Hub Transport servers, Edge Transport servers, Exchange Servers (Hub Transport server only), Externally Secured servers)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50
– Ms-Exch-Accept-Headers-Organization (Kivéve az Externally Secured servers.)
– Ms-Exch-Accept-Headers-Forest (Kivéve az Externally Secured servers.)

ExchangeLegacyServers (Exchange Legacy Interop security group)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50

Partner (Partner Server account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-Accept-Headers-Routing

És legvégül két link a témában jobban elmélyülni szándékozóknak:

No Feature!

Nem, nem a jó öreg Sex Pistols nótáról lesz szó. Rosszabb. Belépsz egy frissen telepített Windows Server 2008 R2 gépre, tennéd fel a kötelező telnet klienst – és nem látsz se feature-t, se szerepet, sőt, amikor rákattintasz az add gombra, kövér hibát kapsz: RPC hiba. Hangsúlyozom, frissen telepített, patchelt oprendszer, semmi extra alkalmazás.
Nyilván újra lehetne telepíteni a rendszert, de csak a foltozás egy fél nap, ergo ha negyed nap alatt megtaláljuk a hibát, már jók vagyunk. (Mint Mr Garrison az üvegcsővel és az egérrel.)
Természetesen gugli. Lehangoló eredménnyel. Némi képzavarral élve, RPC hibával foglalkozó oldalakkal Dunát lehet rekeszteni. Végül csak sikerült megtalálnom a tűt a szénakazalban: Fix my IT system.

A megoldás több, mint érdekes.

Le kell tölteni a Microsofttól egy segédprogramot, a System Update Readiness Tool nevezetűt. Nem kicsi a szentem, közel 100 mega. Ráadásul nem is csak egy böhöm nagy dll, tele felesleges funkciókkal, hanem tényleg dolgozik. Nálam közel 20 percig futott. Átnézte, hogy mi csúszott szét a patchelések során, milyen inkonzisztenciák alakultak ki – és szépen elrendezett mindent. A biztonság kedvéért ráküldtem egy újraindítást – és szépen megjelent az összes tulajdonság és szerepkör.

MAC

Járjuk körbe.

Miért nem érdemes MAC szűrést beállítani az otthoni vagy a céges wifinken?

Ezért.

(A link Fóti Marci blogjáról származik.)

Akkor mégis miért lehet érdemes?

Céges wifinél semmiképpen sem. Ott teljesen másképpen kell megállítani a betolakodót. A MAC szűrés csak hamis biztonságérzethez vezet, nem is beszélve a kellemetlen adminisztrációról.
Otthoni wifi AP esetében viszont mondhatjuk azt, hogy – hasonlóan az ajtónkhoz, vagy a kocsi biztonsági rendszeréhez – minél több akadályt gördítünk a behatoló elé, annál valószínűbb, hogy odébbáll.
Mondhatjuk?
Attól függ, ki a behatoló. Ha csak egy arra kóválygó wifiszomjas járókelő, vagy egy háromnapos emailmegvonásban szenvedő turista, akkor tökmindegy. A WPA/WPA2 úgyis megfogja. (Mert azért megfelelő jelszavas védelemre szükség van. Gondolom, senki nem rajong az ötletért, hogy az otthoni hálózatán idegenek kóricáljanak.) Sőt, ezeket az embereket még a WEP is megfogja, hiszen ritkán túrázik az ember hacker felszereléssel. Hasonlóan jó majomfogó az SSID elrejtése is, csak ebben az esetben nem tudunk üzenni a szomszédnak, hogy takarítson a kutyája után. (Az egyéb lehetőségekről nem is beszélve.)

From Segédlet

Amennyiben célzott támadás ellen szeretnénk védekezni, akkor viszont marad a WPA2, bazi hosszú, véletlenszerű pre-shared kulcssal. (Kevéssé tartom valószínűnek, hogy otthoni hálózatban legyen egy éppen ráérő RADIUS szerver.) Emellé az SSID elrejtése szintén hasznos lehet, a MAC szűréssel viszont csak kiröhögtetjük magunkat. Illetve megnehezítjük az életünket.
Ja, miért nem jó a rövid, értelmes szó WPA2 jelszónak? Ezért.

Mint láthatod, a WPA/WPA2 is törhető, igaz, szótárral.

Akit esetleg jobban is érdekel a téma, innen el tud indulni, az oldal linkjein lesz anyag bőven.