DHCP kötelező

Üdv!
Milyen beállítással/megoldással lehet a DHCP szervert kötelezővé tenni?
Tehát hogy fix (statikus) IP címmel ne lehessen a hálózatra csatlakozni (a user hiába állít be a gépén fix IP-t magának, ekkor ne tudja a hálózatot használni/elérni).

Hozzászólások

Switch oldalon dhcp snooping + arp inspection (legalabbis cisco igy hivja ha jol remlik) -al beallithato hogy csak azokat az arp forgalmat engedje ami dhcp forgalom alapjan generalt adatbazisaval egyezik (src mac+ip).
De ez csak ipv4, bar talan mar van valami hasonlo ipv6 neighbor discovery-re is.

Mukodik win-es dhcp szerverrel is, de relayezett dhcp-vel is. Se dhcp szerver oldalon se kliens oldalon (leszamitva hogy dhcp-vel kerjen ip-t ha jelenleg nem igy lenne) nem kell modositani semmit ehhez, csak switchekben.

Switchet nem az erdekli, dhcp snooping csak elkapja a dhcp uzeneteket, ami alapjan tudja korlatozni hogy melyik portokrol enged dhcp szervertol erkezo forgalmat (dhcp snooping trust port), illetve felepit egy belso adatabzist hogy melyik porton milyen ip/mac parossal volt dhcp uzenet illetve hatralevo ervenyessegi idejuk hogy lejaratkor torolje.
Arp inspection-t meg hozza lehet kapcsolni hogy azt az arp forgalmat engedje ami egyezik a dhcp snooping binding adatbazisban levo ip/mac/port/vlan parossal.
Igy ha a switched tamogatja ezt, akkor egyszeruen leszurheted hogy problemas vlan-okban csak altalad ismert dhcp szerverek forgalmazhassanak (dhcp server vagy relay router es oda meno switch uplink portjaira trust), esetelegesen limitalhatod hogy mennyi dhcp forgalmat engedsz masodpercenkent portonkent (default-ban is van valami limit erre), arp inspection-el pedig megadhatod hogy ipv4 forgalomra csak az az ipv4+mac+port+vlan parosok menjenek amit dhcp szerint megkapott.
Illetve wifi-ben se hiszem hogy lenne ilyen, de a switchben amire kotve van wifi beallithato.

Nem neztem vegig a videot csak beletekertem, de latszolag igen az lenne.

Egyeb opciok ha kb az a cel, hogy csak engedelyezett kliensek forgalmazzanak, ahogy paran mar emlitettek:
1, a most vazolt dhcp snooping: csak ipv4-re jo es wifi-n lattam ilyet, arra kepes switch kell hozza, de egyebkent egyszeruen beallithato es kliens/szerver oldalon nem jar modositassal/megkotessel, persze ha valaki felveszi ugyanazt a mac-et mint egy masik eszkoz es dhcp kiosztja neki akkor az ip utkozest leszamitva megkerulheto, esetleg ehhez hozzacsaphato egy post security
2, 802.1x + radius szerver auth, 802.1x-et egysegesen beallithatod wifin es switchportokon is ipv4 es ipv6-ra is, netan meg azt is megadhatod neki hogy melyik vlan-ban legyen az adott kliens (megfelelo eszkozok eseten), illetve kell hozza radius szerver ami ezt kiszolgalja (opcionalisan ip-t oszthatja tovabbra is auth utan dhcp szerver), mondjuk abban nem vagyok biztos hogy switch/wifi korlatozza hogy csak a radiustol kapott ip-vel forgalmazhasson es ne tudjon felvenni utana egy masodlagos ip-t hogy azzal is menjen neki. Persze lan-on 802.1x-et nem biztos hogy olyan egyszeruen beallit barki.
3, kliens internet kapcsolodast valami ppptp vpn kiepitessel lehet megtenni es pptp szerveren/koncenrtratoron limitalod hogy kiket engedsz, ettol meg local halozatban okozhat gondot, pl kezzel valaki felvett egy ip-t, dhcp szervert dugott fel valaki ami bezavar stb., nem szep megoldas es nem is elterjedt
4, elozohoz hasonlo csak nem vpn-el, hanem routeren limitalod hogy pl fixen feltoltod arp tablat ip/mac parosokkal ha tudod mik a kliensek mac-jei es hozza statikus ip-t kapnak vagy valami acl-el limitalod, ettol meg lan-on belul ha felveszi valaki mas kezzel ugyanazt az ip-t akkor utkozhet es egyeb csunyasagok, mondjuk ezek ellen ha nem kell lan-on kommunikaciot engedni akkor privat vlan-ra is allithatod es akkor kliensek egymassal nem tudnak beszeletni, bar ez meg tippre nem ved az ellen ha ugyanaz a mac 2 vagy tobb porton is megjelenik lan-on belul.
5, ha annyira hozzafersz kliensekhez hogy pl domain policy-t tudsz rajuk kuldeni, netan felhasznaloknak nincs is rajta admin joga akkor policy lekuldessel vagy jogosultsag limitalassal is konktrollalhato csak nem biztos hogy mindenhol limitalhatod hogy csak altalatok adott/adminisztralt/policy szabalyzott kliensek lehetnek csak a halozaton.

Szoval egyertelmu tokeletes megoldas nincs, de ha meg tudod hatarozni igazabol mire van igenyed es milyen eszkozeid vannak akkor jo esellyel lehet elfogadhato megoldast talalni.

Semmilyen :D Lásd még mac address filtering (meg strukturált hálózat (ala NISZ)) :D

Több lehetőség is van, persze attól függ, hogy melyik layerben lévő eszközöd mit támogat. Ezt jó lenne leírnod.

Ha elég okos switched van, akkor ott is lehet akár switchport / MAC cím / IP cím jellegű megkötéseket tenni, de ez konkrétan függ attól is, hogy milyen típusú switched van. Az előnye az, hogy megfelelő konfiguráció esetén a hálózat semelyik részét nem fogja elérni a hibás beállítású gép.

Ha a switched nem managelhető, de mondjuk a routered elég okos, akkor is lehet erre szabályokat tenni, pl. hogy csak olyan csomagot enged át, ahol a MAC cím bizonyos értékű és az IP cím is valamilyen értékű. Persze ekkor a DHCP szerveren is ugyanennek megfelelő konfiguráció kell reservation-ökkel. Ennek a megközelítésnek azért van olyan hátránya, hogy két gép még egymással beszélgethet, fittyet hányva a a router szabályaira.

Helyi hálón ágyúval verébre és még lassú is. Sajna én se tudom,mi a jó. Lehet Radius alapon védeni az ethernet portokat is, hogy legalább idegen eszközt ne lehessen könnyen felcsatlakoztatni.

PS:
Esetleg PPPoE, de az is nagy vízfej.

Pl Mikrotik gateway esetén megoldható a Static ARP, ahol az ARP táblát a DHCP server tölti fel a lease-ekkel.
Persze, a többi gépet ettől még elérheti - de internet vélhetően nem tőlük csepeg.

1. Enterprise megoldás: Cisco ISE, 802.1x, Group policyból lenyomni kliensekre a kötelező szabályokat (Windows-os kliensek esetén)
Előny: működik
Hátrány: Drága.

2. Egyszerű megoldás: Felhasználói oldalon ne legyen jogosultsága az adott felhasználónak átállítani a hálózati beállításokat
(op.rendszertől függetlenül)
Előny: Olcsó és egyszerű.
Hátrány: Nem minden esetben megoldható.

Egyébként specifikálhatnád jobban a környezetet (milyen eszközökön szeretnéd ezt megcsinálni?)

--------------------------------
...úgyis jönnek...

Elméletben - és a marketing slideokon - biztosan van erre megoldás, ám a gyakorlatban ez eléggé szélmalomharc jellegű küzdelem.

Én máshonnan közelítemém meg a dolgot.
pl azzal kell(ene) kezdeni, hogy mi a valós probléma?

--
zrubi.hu

A fent említett megoldások lesznek a jók. De innen jött a kérdés:
* DHCP szerver: win2008R2, switch: cisco 2960s
* DHCP úgy van konfigurálva, hogy a kiosztható címtartomány megegyezik a terjesztésből kizárt címtartománnyal (hogy ne kapj címet ha rádugod a hálózatra a géped).
* címeket a DHCP fenntartásból oszt ki.
* probléma pedig az, hogy ebben a fenntartások táblában időről-időre néhány cím átíródik BAD_ADDRESS-re egy fake MAC címmel. --> fix IP-t beállítva rákötnek gépe(ke)t a hálózatra felhasználók.

ok, de mi a baj azzal ha fix IP-t beállítva rádugnak egy gépet a hálózatra?
Mert ebből az indoklásból nekem csak az jön át, hogy ezt a szitut DHCP szervered nem szereti.

Legtöbb esetben már a (vélt) probléma megállapításánál (is) hibáznak, így nem is jó megoldásra költenek majd rengeteg erőforrást - feleslegesen.

Tipikus eset amikor ezzel azt próbálják elérni, hogy csak a "hivatalos" céges gépeket lehessen rákötni a hálózatra - mindeközben pedig teljesen normális ha ugyanezeket a gépeket hazaviszik, otthoni, és/vagy egyéb hálózatra csatlakoztatják, (durvább esetben randon pedrive-ot dugdosnak bele) majd visszaozzák a "szuperbiztonságos" céges hálózatba... aztán csodálkoznak hogy fura dolgok történnek. Persze ha ez egyátalán feltűnik bárkinek is ;)

Véleményem szerint egy hálózatot úgy kell(ene) megtervezni és felépíteni, hogy a rá csatlakoztatott random kliensek miatt ilyen szinten egyátalán ne kelljen "aggódni".

--
zrubi.hu

Pont ez a cél, hogy külsős gépek ne tudjanak rácsatlakozni a hálóra.
Akinek dhcp van beállítva, az oké is. A dhcp másik tartományból ad nekik IP-t és nem kever be.
De gondolom vannak "power userek", akik fix IP-vel próbálkoznak és keveredést okoz (hálózat is ilyenkor megakad) és ugye a dhcp-ben beállított IP címmel a gép nem tud fellépni a hálóra (IP ütközés).

Biztos olyan szintű biztonságot akarsz, hogy adott MAC csak adott hálózati porton csatlakozhat a rendszerhez?
Nem mondom, hogy nincs ilyen, de azért nem túl sűrűn.

Talán egyszerűbb már egy olyan rendszert felépíteni, ahol a frissen illesztett gép egy "network login" képernyőt kap, ahol sikeres (2factor) auth után rendelődik hozzá a MAC címe adott VLAN-hoz...

Csaxolok h azert ez sem csodaszer. Nalunk a bevezetes utan olyan “tailgatet” nyomott a pentester egy 500 Ft-os HUB-al h orom volt nezni (feldugott egy HUB-ot egy kliens portjara, a kliens szepen beautholt certtel/lof4sszal amitol kinyilt a port. A tamado geppel atvette az autholt MAC/IP-t es lehuzta a HUB-rol a klienst aki felengedte a halora. Mivel 8 orankent volt reauth ezert tul sokszor ezt el se kellett jatszani)

Persze ez nyitott switchtol ezerszer jobb megoldas igy is, csak erdemes fejben tartani mielott elkolti valaki az eves budge-t Cisco ISE licencre

Persze: IPSec/VPN/Wifi(WPA2)

Gondold vegig: teljesen lenyegtelen h hasznalod-e a posture-t, hisz itt az a lenyeg, ahogy a tailgates peldaban is mondtam, hogy be akarsz menni egy kormanyhivatalba, es ott a venascanerren atmegy elotted egy kormanyhivatalnok majd X ideig nyitva marad mogotte az ajto, az or pedig elmegy kavezni. Nyilvan lehet a reauth ertekkel jatszani, de akkor sem trivi megtalalni az optimalis reauth time-ot es valamennyi res marad igy is (nem veheted le 1 percre, mert akkor lassan mas forgalmad nem is lesz a halozaton csak reauth).

Ha az ISE bevezetes volt x meretu project, akkor a titkositassal meg lesz 2x-3x: birni fogjak-e a kliensek a titkositott forgalmat? Minden TCP/IP stackkel mukodni fog? Linux/Win/Mac kliens jatszik? Stb-stb, ezer uj kerdest behoz.., mi ezt nem vallaltuk be.

Ahogy zrubi feljebb megfogalmazta, nagyon esznel kell lenni a feladatkiirasnal, mert utolag eleg szar magyarazkodni a managementnek, hogy megsem volt folosen kidobott az y millio krajcar. Es ezek a dolgok persze sosem derulnek ki a gyartoi whitepaper-ekbol :)
Esetleg meg lehet nezni vmi open source NAC-ot ha sporolnal a licencen, de ott meg a support hianya lesz a gond..

Ha jol ertem ezzel csak annyit ert el, hogy ha valaki felcsatlakozik az o altalaba kozbeekelt hub-on keresztul, majd lehuzza az illeto kabelet akkor reauth lerjartaig tudja hasznalni?
Ha jol remlik pl freeradius alapbol 30 perces reauth default configgal van, az meg elkepzelheto hogy usernel alapbol egy utp kabel van es nem veszi eszre igy a kozbeekelt hub-ot, meg talan azt is feltunes nelkul meg lehet oldalni hogy a user kabelet lehuzza auth (es mac/ip masolas) utan, de azert az hogy ilyenkor az illetonek megszakad a kapcsolata es ez ne zavarja, meg ne foglalkozzon vele, mar azert erdekesebb kerdes.
Hat nem tudom, papiron jol mutat, de azert gyakorlatban inkabb mas konnyebben kivitelezheto modon probalkoznak szerintem.

Uristen mirol beszelsz, ahol ISE meretu projektrol szo van(nagyvallalat) ott talalni epp nem hasznalt klienst, kisse elhagyatottabb irodai reszt stb.. (login sem kell, hisz eleg a gepet bekapcsolni es authol a halozatra)
Es ilyen cegeknel kismillio alvallalkozo(melosruhaban mesz, meg a nagyforgalmu irodaban se kerdezi meg senki, h mit maszkalsz az asztal alatt), out es insourced emberke jar kel gyakorlatilag feltunes mentesen.. Maximum a vendegkartyasokat szoktak kisergetni, de ugy osztjak a kulsos kartyakat is mintha nem lenne holnap es ott mar a legtobb cegnel kisero se kell
Nyilvan random kis kft nem ISE-re/NAC-ra fog kolteni, van ezer mas baja

Egy elvi hibat meg osszemosol azzal, hogy erdemesebb a phish ellen vedekezni hisz ott jobban probalkoznak.
Ez egyreszrol igaz en is ezt tennem, masreszrol viszont nem errol szolt a postom, hanem arrol, hogy tudd annak a megoldasnak a hatranyait is, nem csak az elonyeit amit rad probalnak sozni a marketing gepezetek..
Nem azt mondom h itt fog megtortenni a breach, hanem azt h itt IS megtortenhet es sajnos mindig a defend csapat van hatranyban. Nekik egyszerre kell vedeni 100 ajtot az attack csapatnak meg a 100-bol eleg egyet megtalalni es utana mehet a defend team a szonyeg szelere...

Nem mondtam, hogy nem hibalehetoseg csak vannak egyszerubbek is.

Az hogy ha egy szamitogep alapbol feljelentkezik bekapcsolas utan a halozatra ilyen erovel nagyobb hiba, mert akkor ha mar hozzaferek fizikailag a gepekhez akkor keresek egy hasznalaton kivulit es fellepek a halozatra azzal.
De vegyuk azt az esetet, hogy ez nincs meg, ha felhasznalo bejelentkezik a rendszerbe akkor azzal az azonositoval csatlakozik fel 802.1x-re vagy old fel egy titkositott tarhelyet ahol tarolva van az ehhez szukseges kulcs+script, majd elmegy egesz nap meetingekre, netan ki se lep nap vegen a gepebol es akkor mar ha valaki "kenyelmesen" fizikailag be tud jutni akkor hozzaferhet a halozathoz. Erre viszont azt mondom hogy fizikai biztonsagon lehet javitani, vagy akkor a halozathoz hozzaferes meg ne jarjon alapbol rendszerekhez azonositas nelkuli hozzaferessel.

Nem latok erdemi kulonbseget. Elozo nap odateszed a HUB-ot, masnap visszamesz es megteszed amit meg akarsz mig a "kuncsaftod" meetingel.
Motozasra gondolsz? Keressenek HUB-szeru eszkozoket a taskakban? Nem eletszeru.

Ezert mondtam az IPSec-et, mint lehetseges megoldast. Ott nem eleg az auth, folyton nalad kell legyen a kulcs h kommunikalni tudj a halozaton.
Az mar mas kerdes h ezer mas vonzata van: neheziti a halozati problemak debugolasat a titkositott forgalom, van valamekorra plusz overhead ezert lehet h regebbi gepek belassulnak ha halozat intenziv feladatuk van, stb-stb...
Fizikai biztonsaggal viszont sztem ez nem kezelheto erdemben

Nem teljesen, mert elvileg beautholni csak az tud, akinek beállította a rendszergazdi a gépét, az meg hogy fixIP vagy DHCP, nagyon spéci helyzetektől eltekintve (de még akkor se talán) egyedül a rendszergazda jogosultsága. Aki meg maszek gépet hoz, azt fel se engedi a LAN-ra.
Namost írták, hogy megkerülhető HUB-bal, tehát ez se egy hű de százas megoldás, de hacsak direkt meg nem akarják kerülni támadási célból, csak épp valaki rátolná a maszeklaptopját, már azért megfogja.

Igen, ez volt a lenyeg, amire ra akartam vilagitani. Ahogy Te is irod, a maszekolasra jo, de kerdes, hogy emiatt megeri-e a licenc vonzat/support koltseg, uzemeltetesi plusz overhead (nyilvan ha baja van meg kell nezni mi az)
Celzott/felkeszult tamadas ellen mar nem ved onmagaban.
Ma mar nem biztos, h bevezetnem: sztem egyszerubb elterelni az atlag office joskat Wifire es csak annak adni fizikai vegpontot, akinek muszaj (pl: nagy adatforgalom/sebessegre van szuksege a meloja miatt).
Ami miatt esetleg megerheti, az a posture ellenorzes(ujabb plusz licenc Cisconal), de azzal is valag plusz terhet rosz az uzemeltetesre, mert nem fogja felengedni a halozatra az elavult virusirtoja miatt. Vagy ami megjobb nem elavult, csak a posture kliens nem tudja lekerdezni az antivirustol mert az frissult es eltort az API es persze a gyarto meg nem kovette le.

Szoval az egesz 802.1.x egy erdekes es nagy tema :D

Innen jött a dolog:
* egy fake mac address után a hálózat belassul, pl. a wireshark log (10.0.0.15 a dhcp szerver IP címe.): https://justpaste.it/1dgms
* a DHCP-ben megjelenik a BAD_ADDRESS bejegyzés
* majd ha a BAD_ADDRESS átírásra kerül, - visszaírjuk az eredeti, jó MAC címet - a hálózaton minden visszaáll normális állapotba.