[vaegkuulja]

Mida võiks peale hakata illegaalsete DHCP serveritega MS domeenis? Tundub et MS'l on see täiesti nõrk koht kui mitte lausa turvaauk. Authorized DHCP servereid nagu ikka on ainult üks ja domeenimasinatest keegi muu DHCP serveriks hakata ei saa. Kui enamasti need illegaalid polegi domeeni masinad ja serveerivad DHCP'd ilma mingi takistuseta. Domeenimasinad, kui IP'd küsivad, saadavad udp-68 pordist välja broadcasti udp-67 porti. Nüüd aga võib iga kaabakas vastata ja MS'i domeenimasin aktsepteerib ilusti kohe igast saasta. Tõenäoliselt oleks vaja tulemüüri igasse masinasse, kuid see tulemüür peaks lisaks olema suht spetsiifiline - ta peaks filtreerima reply pakette, lubama ainult DHCP serveri IP'lt (või MACilt) broadcastile reply pakette udp67,68 portide vahel. Ma isegi ei tea mis tulemüür seda suudaks - windowsi enda oma mitte, kasperskyte ja muude taoliste omad samuti mitte. Järgmine probleem oleks kohe selles, et sellise otstarbega tulemüüri investeering peab jääma reaalsuse piiresse (ei saa ju ainult selle eesmärgiga varustada tohutu hulk masinaid mingi üüratu kalli tarkvaraga). Teisest küljest jälle on sellise liba-DHCP serveri salaja toppimine kuhugi ju ideaalne sabotaaz näiteks konkurendi kontorisse. Olen kuulnud ka et mingitel kallimatel switchidel on selline filter täitsa olemas, kuid ka see tähendaks investeeringut (vahetada kõik switchid välja).

[Andrus Luht]

Vähegi korralikum L3 switch oskab sellist liba-dhcp-serverite liiklust piirata...

[High-Q]

oskab ka L2, aga vastavad funktsioonid peavad toetatud olema.

dhcp-snoopingut peaks ka keskmise taseme seadmed (st siiski neljakohaline summa per device) oskama.

[Andrus Luht]

DHCP Snooping on küll L2 tehnoloogia aga teevad seda ikka üsna high-end L2 switchid. Enamasti L3 pärusmaa...

[High-Q]

kas procurve 2610 on high-end switch? keskmine letihind on sellel u 6000 kr (hetkel muidugi promo tõttu, muidu vast u 20% kallim)

[Angrist]

Ainuke asi mis MS vahenditest pähe tuleb on sisse lülitada IP-Sec. A ma võin selles eksida ka, sest ma ei tea kas IPSEC lülitub sisse enne või pärast IP kättesaamist. Ja on ka paras hambaaugu ravimine rektaalse avavuse kaudu.

[vaegkuulja]

[Andrus Luht]

vaegkuulja, vabavaraline võrguswitch!? Nalja teed, eksole...
Ainuke reaalne viis ennast kaitsta liba-dhcp servude vastu on switchi vastav tarkus.
Teoorias peaks olema võimalik ka selline variant, et kui tööjaamad üksteist nägema ei pea siis ajad iga pordi eraldi VLAN'i ja õige DHCP server/tulemüür on ainus masin, mida nad kõik näevad...

[vaegkuulja]

[kännuämmelg]

[vaegkuulja]

[Nickelby]

Olen küll võrguasjades võhik, aga minu loll loogika näeks hetkel, et kui switch oskaks selle asja mis sul vaja nüüd ära piirata, suunata vms ise ära teha siis need masinad mis sellest switchist seespool on peaks turvatud olema? Või?

[kännuämmelg]

[vaegkuulja]

[Andrus Luht]

[vaegkuulja]

[kännuämmelg]

[High-Q]

imho selline softilahendus ei päästa eriti.
windows serveri NAP dhcp enforce on üks variant, aga see on vast veel kallim ja antud olukorras overkill, lisaks veel nõuaks see 802.1x toetavaid võrguseadmeid ja tulemuseks eeldatavasti sama seis.

alati on variant tööjaamale mingi tsentraalse managementiga (ja tsentraalsete policyte laialisaatmisega) antiviirus/tulemüürisoft, mis lubaks teatud portidel liikluse ainult kindla IP peale, aga eeldan, et sellise lahenduse hind jääb tublisti üle switchide soetamisele. keskmine säärane AV soft läheb maksma 3 aasta peale u 500 kr per masin, mis 24 masina puhul (võrdleme ühe switchiga) tähendaks ligi 2 korda suuremat hinnavahet võrreldes switchi põhisele turvalisuse.
Pealegi on säärane asi võimalik rakendada ainult püsivalt selles võrgus olevatele masinatele ehk lauaarvutitele, kuid sülekatele, mis mööda erinevaid võrke ringi rändavad, säärast piirangut panna ei saa.
muidugi eeliseks on iga arvuti viirusetõrje softi olemasolu, mis windows keskkonnas niivõinaa kohustuslik on.

eraldi vlan-id ei ole sugigi hea idee, sest eeldan, et ees olev ruuter ei ole teps mitte super-klassist ja kõige kolhoosi võrguliikluse ajamine läbi lihtsa layer3 ruuteri paneks tolle kergelt öeldes sussid püsti, sest ruuter on mõeldud liikluse juhtimiseks, mitte bittide transportimiseks. lisaks eeldan, et sellise arvu vlanide majandamine ja üleüldse võimalus on kaheldav.

tooks paralleeli ehitusega: kui sul ikka betoonseina auku puurida vaja, siis kasutad selleks lööktrelli. võid ju käsi- või akutrelliga nühkida, vahepeal meisli vms peksta. vb väikse tüübli jaoks võid tulemuse saavutada, aga kas asi on seda väärt?

moraal: iga töö jaoks oma tööriist.

[Andrus Luht]

High-Q, mina sain teemaalgataja jutust aru, et lisaks oma firmale elab nende eetri otsas veel n+1 tegelast. Surada need tegelased eraldi VLANidesse pole üldse paha mõte kuna ainus teenus, mida nad eeldatavasti tarbivad sealt võrgust ongi omavaheline suhtlus VLAN'i piires ja internetiteenus ning see ei koorma kuidagi rohkem netiruuterit.

[vaegkuulja]

[High-Q]

taoliste skriptide progemise hind võib kokkuvõttes hulgi kallim tulla (kui keegi just harrastuse pärast seda ei tee) kui switchi-paari soetamine.
tõesti, mitme firma situatsioonis on erinevate vlanide kasutamine vajalik (isegi põhimõtte pärast, mitte ainult turvalisuse/privaatsuse), seega see oleks prioriteet nr 1: jagada võrgud väiksemateks loogilisteks võrkudeks. sellega kaasneb üks aga: ruuter peab olema võimeline mitme vlani samaaegset ruutimist ning switchid vlani toega (või füüsiliselt täitsa eraldatud mittemanageeritavad, st igale vlanile eraldi switch ja ruuteris eraldi port, sellisel puhul pole switchile tarkust vaja).
see vähemalt säästaks teisi kasutajaid, kui keegi oma risu võrku topib ja serverit mängima hakkab.

[vaegkuulja]

[Andrus Luht]

vaegkuulja, kui sa ikka iga kliendi topid oma võrguga eraldi vlan'i siis ainus, kellele ta siga saab teha on ta ise. Kedagi teist see ei koti.

[vaegkuulja]

[Andrus Luht]

[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]