[vaegkuulja]

[High-Q]

hei, ka võrguseadmete peal olevad rakendused on tarkvara.

Võrgumaailmas on teatud piirangud. võlu sa softi oma domeeniserverile palju tahad, aga suurt kasu sellest ei saa.
sinu kahjuks on minu teada sinule sobiv soft ainult kategoorias Network Access Control (NAC, aga tootjad kutsuvad seda igaüks endamoodi), mida viljelevad lisaks Microsoftile endale näiteks Juniper Networks, Cisco systems ja mõned tegelinskid veel. Küll aga on trend NAC-i puhul see, et seda pakuvad võrgutootjad, keda, nagu paistab, sa väldid.
Samuti on NAC väga keeruline süsteem, mis teps ei koosne mitte ühest serverist ja selles olevast softist, vaid NAC-i eelduseks on kogu süsteemi piires 802.1x või vastavat tootjaspetsiifilist protokolli toevavad süsteemid (alates lõpptarbija masinast või printerist, lõpetades ääreruuteriga). Eelarve 100 masina nacitamiseks on julgelt kuue kui mitte seitsmekohaline.

muidugi võiks mõelda Radiuse põhist autentimist, aga ma ei tea, mis määral see päästaks võrgu risustamisest.

[vaegkuulja]

[High-Q]

kui see kõik nii lihtne oleks olnud, siis oleks see ammu tehtud.
küsimus on just "millal rakendada reeglit". dhcp puhul ei ole mitte mingit vahet kas on rogue dhcp või mitte. kogu liiklus käib täpselt sama moodi ja paketti inspektides ei ole mingit vahet, kas on õige või mitte.

sinu juhtum on u selline:
võrk lan1
dhcp ip1
võrgukaardil ipstacki tasemel peaks olema mingi reegel a la:
if dhcpoffer võrk lan1 and dhcp ip1 then dhcpack
else dhcpnack

aga mis juhtub, kui juhuslikult keegi jagab just samasugust võrku nagu sa praegu ja justsamasugust dhcp-d? näiteks väga tüüpiline 192.168.1.1. ega ruuteri või serveri poolt ära keelata ei saa, kui vahepeal l2 tasemel on võrk lubatud.
ok, lahendus kasutada vähelevinud aadressivahemike (10 võrgust tavaliselt defaultina seadmetes kasutatakse harva).

mis teha aga liikuvate masinatega või sülearvutitega? seda ju kliendipõhiselt enforceda ei saa. üleüldse on sul keeruline sinupoolselt midagi enforceda, seda saad teha ainult enda halduses olevatele masinatele.

vot just 802.1x, nac ja muu siuke mudru ongi selleks mõeldud, et enne dhcpacki ja võrguaccessi luba kontrollib lõppmasina tervist. Kui tervis on korras (lisaks muudele parameetritele ka näiteks kas viirusetõrje uuendused on laetud või mingid servicepackid pandud), siis tere tulemast, kui mitte siis, kas a) access denied või b) paigutada vend quarantine vlani, et oma süsteemi parandaks/uuendaks.
kahjuks pole säärast asja vabavaraliselt veel leiutatud ja lisaks sellele vajab säärane toiming ka võrguseadmetelt tingimusi (näiteks vlani paigutuse koha pealt dünaamilise vlani määramine mingile pordile või siis tingimuslikku port shutdowni). me oleme suurtel tallinna võrgupidudel (üle 200 kasutaja) praktikas paar korda sellist asja viljelenud (ciscode baasil: port security ja dhcp snooping, pluss veel blaster tüüpi viiruste vastu broadcast stormid jt) ja toimis superluks, ühtegi rogue dhcp-d ei toiminud.

kuda sa muidu broadcasti kontrollid? seda saaks teha broadcast domainidega (vlanide või ruuteritega), aga nagu näha, see ainult elimineeriks osa murest. ükski lõppserver ju broadcasti ei kontrolli ja ruuter seda enne iseennast ära keelata ka ei saa, seega rogue dhcp saab vabalt toimida.

sinu probleem on praegu võrgus, mitte lõppklientidel või serveris või ruuteris. seega võiks olla ka probleemi lahendamine võrgupõhine.

[vaegkuulja]

[High-Q]

ei. 802.1x ja taoliste protokollide puhul käib tuvastamine enne autentimist ja võrguliikluse lubamist (vähemalt juniperil ja ciscol on nii).

[vaegkuulja]

[Andrus Luht]

vaegkuulja, miks igale masinale oma vlan!? Gruppeeri neid klientide või tubade või korruste või krt teab mille järgi. Ja vlan'indus ei tee teps mitte suurt koormust. Mitte oluliselt suuremat kui ilma vlan'ita switchimine...

[vaegkuulja]

[High-Q]

väike kordus. vlanidega võrkude segmenteerimine ei lahenda sinu probleeme, vaid jamade tekkimisel säästab osasid. piltlikult öeldes: kui sul 100 kasutajat ja jagatud 10 kaupa 10-sse vlani, siis kui ühes jama juhtub, siis vähemalt ülejäänud 90 saavad rahus elada. see pole lõplik lahendus, vaid workaroud probleemide isoleerimisel.

vaata, lõpptarbija masina poole pealt, kui sellel ei ole ipstacki põhiselt ära piiratud, kust täpselt ja mis tingimustel dchpofferit vastu võtta, ei ole mingit kontrolli broadcasti pealt tuleva trafficu eest. kui tema karjub oma dhcprequesti välja, siis dhcp serveri olemasolul ja selle korrektsel funktsioneerimisel saab see ka dchpofferi ja asi toimib. lõpptarbija ei tee sooja ega külma, kas see on AD, linksysi ruuter, windows ICS või mingi pahatahtlik värk. nii kui ip aadressid käes, nii on ka võrk aktiveeritud antud masina ja dhcp serveri gateway ning samas võrgus olevate masinatega.
väga tüüpiline pahalaste olukord: firma sisevõrk, igati müüritud. tänapäeval on kasutuse väga palju laptoppe ja ülla-ülla, mitmed kasutajad kasutavad arvutit nii, et samal ajal nii wifi kui lan on aktiveeritud. tuleb tegelinski oma suvalise wifi purgiga ja pistab kuskile üles. loomulikult leidub mõni läpakas, kes sellesse jurakasse ennast ära konnektib ja voila: oledki otsaga sisevõrku avalikku wifisse välja hõikamas.

autentimise (radius, 802.1x, nac) puhul käib enne võrguaccessi lubamist teatud checkid, mis vaatavad üle, kas on tegu ikka õige inimesega (kas tehakse see kasutajanime/parooliga või masina maci pluss muude asjadega või mitu asja korraga) ja alles siis lubatakse ta uude võrku, kus õiged inimesed peavad olema. lihtsalt osad protokollid oskavad seda nii teha, et kontroll tehakse enne võrguaccessi lubamist (kas dünaamilise guest vlani määramisega või spetsiifilise protokolli abil).
nüüd ei radius, ei 802x1 ega nac ei päästa tegelikkuses rogue dhcp ja sinna konnektimise eest, kui layer2 tasemel broadcasti liiklus ei ole kontrollitud. need päästavad ainult selle eest, et vale vend õigesse võrku ei satuks.

seni kuni layer2 tasemel ei ole mingit kontrolli, ei saa sa võrgusiseselt midagi piirata. see mis ei ole keelatud, on lubatud, ja vsjoo. asi mutt. ühe broadcast domaini piires dhcp-messaged saavad rahumeeli koos ringi vantsida. enamik dhcp servereid oskavad küll karjuda, et "duplicate server found", aga ega nad ei saa selle vastu midagi teha.
kui seda teha lõppkasutaja võrgukaardi poole pealt, siie ega see ei säästa sind liba-dchp-dest, need jäävad ikka võrgu toimima, lihtsalt teatud reeglite kehtestamisel nende dhcp-offerit vastu ei võeta. dhcp on aga selline peen teema, et vähegi liikuva masina puhul hakata keerulisi reegleid tegema ei ole lahendus.

minu aus arvamus: lõpptarbija tasemel (olgu see mingi windowsi skriptiga, tööjaama firewall softiga vms) liba-dhcp-sid "püüdmine" ja keelamine toimib vaid väga teatud kitsates tingimustes ja reaalselt probleemist see lahti ei saa. see on nagu magamiseks sääsevõrku riietumine: tore ju küll, sääsk ei pääse suskama, aga äkki oleks lihtsam see sindrinahk hoopis maha lüüa ja rahus normaalse inimese moodi magada.

siin ongi lahendused:
lahendada asi layer2 kontrolli tasemel võrgusiseselt ja kõik mured kaovad
lahendada asi layer3 vlanide tasemel (või eraldi ruuterite abil, kui seadmed vlane ei toeta) ja mure suudab elada vaid osaliselt piiratud "ruumis"
lahendada asi layer7 tööjaama applikatsiooni tasemel ja mure antud tööjaama ei puutu, aga võrgust reaalselt ei kao.
layer5-l baseeruvad authentication ja authorizationid tegelikult ei aitagi midagi. sinu puhul on see tegelikult juba AD näol juba olemas.

teisi lahendusi ei ole

väga hea kirvereegel võrguprobleemide lahendamisel: mida madalamal osi tasemel sa probleemi isoleerid, seda parem on tulemus. kõike muidugi ei saa madalal tasemel teha, aga kui on võimalus, siis see on alati parim valik.

[vaegkuulja]