WiFi hálózatok szeparációja

1,259 views

Published on

IIR szakkonferencián tartott Vezeték nélküli hálózatok szeparációja vállalati környezetben előadás

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,259
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide


  • Mit szeretnénk elérni? A cél minden esetben az erőforrások megosztása, elérhetővé tétele a látogatóknak. Természetesen ezek a látogatók többfélék lehetnek, az éppen valamit bemutató sales-es, közös projekten dolgozó partner, vagy egy tárgyalásra ékrező üzletfél. A jogosultsági szintjük jellemzően lehet más, de akár ugyan az is.

    Tapasztalatom szerint ha olyas valaki kerül be átmenetileg a rendszerbe, akinek a belső hálózati erőforrásokhoz is hozzáféréssel kell rendelkeznie, a rendszert üzemeltetők inkább teljes körű hozzáférést biztosítanak, mint hogy a vendég wlan felé nyissanak bizonyos hozzáféréseket. A piacvezető gyártók trendje is ezt az irányt célozza, azaz leginkább az internet hozzáféréshez nyújtanak megoldást, a teljes vállalati infrastruktúra megosztásához nem.
    Természetesen ez nem azt jelenti, hogy nem lehet a teljes infrastruktúrával összehangolni.

    Az eredmény mindig ugyan az: erőforrásokhoz kívánnak hozzáférni.
  • A lehetőségek mellé majdhogynem automatikusan jár a biztonsági problémák egész sora.
    Ki férhet hozzá a vendég wifi-hez, ki internetezhet róla, az internet irányában milyen forgalmakat engedünk? Jellemzően különböző cégek különböző módon oldják meg a roadwarrior csatlakozásokat, azaz ha valamilyen szűk hozzáférést biztosítunk az internet irányába, előbb vagy utóbb annyi lyukat kell ütni a tűzfalon, hogy egyrészt karbantarthatatlan, másrész követhetetlen lesz. Verzió követés, rollback? Talán.

    Fontos kérdés, hogy védjük e a vendégeink rendszerét illetve kommunikációját, vagy bízhatunk abban, hogy ők ezt már megtették helyettünk (host tűzfal, VPN-be routolt forgalom stb)

    Mi a helyzet a rogue AP jellegű támadásokkal kapcsolatban, mit tehetünk a WiFi DoS jellegű bruteforce ellen?

    Milyen lehetőségeink vannak protokoll szinten a védelemre?
  • Nem szabad elfelejtkeznünk arról sem, hogy publikus infrastruktúrát karban kell tartanunk, valamint ha olyan hozzáférés vezérlést alkalmazunk, akkor annak adminisztrációját is ki kell adnunk valakinek.
    A profitorientált vállalatok jellemzően túlterhelt, több funkciós alkalmazottaira újabb feladatot kell rátennünk, viszont remek lene, ha ezzel nem sűllyesztenénk el őket a bitekben mindörökre.

    Nézzünk meg egy belvárosi iroda házat, a körülötte levő WiFi zaj szempontjából. Milyen megoldásokat lehet használni a túlterhelt spektrum ellen? Ki figyelje ezek változását, és ki kövesse ezeket? (A hogyan dokumentáljuk de egyáltalán érdemes e ezt dokumentálni?)
  • Hát azt kell, hogy mondjam, az üzemeltetés oldali kérdésekre a WiFi standard nem ad megoldást, ezekre max a gyártók készülhetnek (és készülnek) fel valamilyen egyedi módon.

    A 802.11 szabvány eredetileg a WEP (Wired Equivalent Privacy) lett megalkotva a WiFi védelmére. Nem akarnék sok szót vesztegetni erre, 2004 óta tudjuk, hogy ez a megoldás elbukott. És igen, bármilyen erősséggel, kulcs-cserével is van megáldva, a WEP elbukott. Szót sem érdemel többet.

    A 802.11i szabvány megalkotása azt hivatott összefoglalni, hogy milyen lehetőségek kerültek bele a protokollba menet közben, illetve mik azok, amiket a legmagasabb biztonsági szinten is elfogadnak, mint megoldás.

    Érdemes kétfele vágni a lehetőségeket, vegyük az egyiket a SOHO kategóriának, másikat pedig enterprise szintű megoldásnak.
    Van lehetőségünk TKIP vagy AES titkosításra, illetve jelszavas, tanúsítványos authentikációra. Ezek használata természetesen cég méret, felépítés és technikai megfontolás eredménye kell, h legyen.
    De milyen irányból hat ez a vendégek hálózat használatára? Jelen pillanatban a legjobban védhető megoldás az EAP-TLS, amit akár a méltán híres (hírhedt) NSA is elfogad, mint biztonsági standardot.

    Ha törekszünk a biztonságra, akkor beállítunk egy cert alapú authot. Mivel senki sem ül milliókon (legalábbis ebből a szemponból) az authra használt x.509-es certeket feltehetőleg self-signed cert fát fog felhasználni. Vendégünk szemponjából ez azt jelenti, hogy legalább egy root, és egy saját certet kell telepítenie ahhoz, hogy használhatóvá váljon a WiFink. Mivel nagyvállalati környezetben legalább a root containerbe telepítés rendszergazdai jogokhoz kötött, ez a vonal meglehetősen körülményes.
    De mondhatjuk ezt bármely certet érintő megoldásra is. Használatuk, legalábbis a vendégek szempontjából, lassú és nehézkes.
    Nézzük a másik végletet, a PSK alapű belépést. A felhasználónknak egy SSID-t és egy jelszót kell megadnunk, amivel máris átjárhat az internet irányába
  • Mi van a nyitott hálózatokkal?

    Tudjuk, hogy nyitott hálózat esetén bárki csatlakozhat a WiFi-hez, illetve a rajta folyó kommunikációt, akár kilóméretekkel távolabbról is le lehet hallgatni. A lehallgatást innentől kezdve mi, mint a WiFi hálózat üzemeltetői nem fogjuk tudni megakadályozni, ezt rábízzuk a vendégünkre. (Ha jogász van a teremben, és van kedve, írjon az erre az esetre ráhúzható perekről egy 40 oldalas tanulmányt, köszönöm)

    A felhasználónkat viszont érdemes azonosítani, ha másért nem csak a miatt, hogy illetéktelenek ne tudják még az internet kapcsolatunkat sem saját céljukra használni (és akkor itt jöhetnek a buzzwordok, mint gyerekpornó bankkártyák adományozása stb)
    Erre akár nyílt forráskódra építve, akár megvásárolva remek megoldásokat kaphatunk. A titkárnő/recepciós pedig néhány kattintással felvihet új felhasználót jelszóval, illetve törölheti is ezt a jogosultságokat.
    Hatalmas előnye lehet ennek a megoldásnak (vagy bármely más megoldással történő ötvözése), hogy személyhez köthetjük a hozzáférést, így akár az internetezhet vagy sem kérdéskörnél sokkal komplexebb döntési mechanizmust is köthetünk az azonosításhoz. Pl hozzáférhet e bizonyos belső hálózati szegmensekhez az adott eszköz.
    Természetesen itt is kérdés az üzemeltetés, a felhasználók követése és kiírtása.
    Meg persze az, hogy akarjuk e, h a captive portálunkig is eljusson e bárki, akár a parkolóban ülve.

  • Fizikai vonalak
    Már látjuk, hogy milyen lehetőségeink vannak a felhasználó és az AP közötti kommunikáció védelmére, valamint a felhasználó azonosítására. Nézzük meg, hogy mit tehetünk a vállalati infrastruktúra védelmében.

    A legbiztonságosabb megoldás az lenne, ha minden egyes AP, de legalább is minden egyes zóna azonos fizikai hozzáféréssel rendelkezne a rendszerben, azaz nem lenne átjárás a WiFi által kiadott.
    Ez persze sok esetben már nem lehetséges, hiszen a meglevő fizikai infrastruktúra bővítés körülményes és drága.

  • A VLAN használat már egy lépéssel közelebb van az ideálishoz, lévén a már meglevő infrastruktúrára illeszkedik, jellemzően központilag konfigurálható (switch/tűzfal oldalon) és feltételezzük, hogy védelmet is nyújt a külső illetéktelen kommunikció ellen.
    Mi itt a gond? Egyrészt a VLAN-on belül a kommunikáció lehallgatható - bizalom a vendég és az internet elérést adó cég között, másrészről egy konfigurációs hiba okán akár a teljes belső hálózatunk elérhetővé válik a hálózatot használó előtt. Egy nyitott hálózattal egybekötve ez fergeteges murira adhat okot - vagy hívhatjuk egy hatalmas biztonsági incidensnek.
  • A piacvezető WiFi gyártók, mint pl az Aruba vagy a HP olyan köztes megoldással állt elő, amely ötvözi a fizikai hálózat relatív biztonságát, és a vlan-os konfiguráció hatékonyságát.
    Az AP egy VPN csatlakozást indít a központi concentrator felé, amely lehet a gateway egyik dedikált zónájában is. A VPN-be zárt kommunikáció miatt sem a vpn-ből ki, sem a VPN-be be nem lehet olyan forgalmat küldeni, amely bármelyik oldalnak tartania kellene (természetesen a VPN végponton még mindig lehet az egyébként nem megfelelően védett kommunikációt támadni), emiatt akár egy VLAN szeparáció is elégséges védelmet nyújt az ilkyen kommunikációhoz.
  • Nos igen, a csatornák. A 2.4-es WiFi szabvány sajnálatos módon a 13 csatornából összesen 3 olyat tud felmutatni, ami egymástól megfelelő távolságra van. Pontosabban kettőt, ha beleszámítjuk a mikrohullámú sütőket és BlueTooth ketyeréket, amelyek pont azon a frekvencián kommunikálnak, mint a középső 6-os WiFi csatorna... Mondjuk egy Budapesti belvárosi irodában nagyjából lehetetlen megfelelő fix csatorna kiosztást találni a saját hálózatunk számára.

    A nagy gyártók ezt szintén egy ügyes trükkel oldották meg: az AP-k monitorozzák a körülöttük levő hálózatokat, és a túltelített spektrumról átugranak egy megfelelően távolira, hogy a rádiós zavar minél alacsonyabb legyen.

    Mi van a DoS és rogue AP elleni védelemmel? Természetesen erre is van megoldás: mivel a DoS egy igen primitív, cserében hatékony támadás, védelem ellene nehezen van. Lehet hoppoltatni másik csatornára az AP-t, lehet ellentámadást indítani, vagy legrosszabb esetben az AP saját magát is kikapcsolhatja - legalábbis a rádióját. Mondjuk ez utóbbi esetben a támadás elérte a célját, az adott AP elnémult.

    Mi van a rogue access pointokkal? Az AP-k a csatorna váltogatáson kívül képesek a nem ismert SSID-jű hálózatok DoS alá vételére is, magyarán ha egy HP rendszert csak “kidobunk” a hálózatunkra, akkor a hatókörbe eső szomszédos hálózatok néhány másodpercen/percen belül elnémulnak. Tény, h ez által nem lesz szükségünk a csatornák váltására, viszont a szomszéd vállalatok illetve az NHH hamarosan kopogtatni fog az ajtónkon.
    Erre van egy jó story-m
  • Meg lehet e ezt oldani open source forrásból?
    Részben igen, részben pedig nem.

    A HuWico tagok java részt open source fétisiszták, unix és linux operációs rendszereken szocializálódtak. Ennek mi a folyománya? “Mindent meg lehet oldani, ha a linux kernel tudja!”
    Csak szabadon köszlva, és a teljesség igénye nélkül:
    OpenWRT az AP-ra, IpSEC vagy OpenVPN támogatással, ChilliSpot vagy WiFiDOG (ez már lehet, h nem élő projekt) Radius/LDAP integrációval captive portálként, és ha megfelelő chipsetű kártyánk van (Atheros) akkor több különböző (AP és monitor) módban futó WiFi-t létrehozva némi shell scripttel támogatva összerakható a channel hopping és rogue AP detection/protection is. Ha akarunk egy SNORT-ot is telepíthetünk, amivel akár külön eszközzel IDS - switchekkel együttműködve IPS megoldást is szállíthatunk.

    Előnye? Kiváló néhány napos/hetes DIY projekt. Hátránya? A supportot adja hozzá egy nagyvállalati környezetben aki kétszer állt sorban a bátorság pirula osztásnál. Vagy még inkább háromszor.

  • WiFi hálózatok szeparációja

    1. 1. Szeparáció és vendéghálózatok a vállalati wireless rendszerben
    2. 2. Miről lesz szó? Célok Problémák (technológia és biztonság) Megoldások
    3. 3. Biztonsági problémák
    4. 4. Support
    5. 5. Megoldások a “dobozból”
    6. 6. N is y su n k ?
    7. 7. Fizikai vonalak
    8. 8. VLAN
    9. 9. VPN
    10. 10. Köszönöm a figyelmet!

    ×