Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Hamparle 01. 09. 2020, 13:30:59
-
Jak běžná je funkce, že síťový prvek (kam se strká kabel do sítě) "nedovolí"* připojit "cizí zařízení"(to které si IP adresu nastaví přímo místo toho, aby se zeptalo DHCP.) Má tato funkce nějaké pojmenování? Jak moc je k užitku a kde a se obvykle používá? Je lepší to řešit na 2 nebo 3. vrstvě?). Prostě že zařízení, která budou mít IP adresu nastavenou staticky v síti budou "zablokované".
Logicky dhcp démon server to nemůže řešit, protože to je jen sl užba na portu 67,68 a nikoli firewall.
* to je jen lapidární formulace. Připojit nezabrání, ale myslím tím, že zatrhne komunikaci (například tak že tam bude firewall, který defaultně blokuje traffic mezi IP kromě 0.0.0.0 a 255.255.255.255 a kromě těch které prošly DHCP přiřazením(dynamický seznam)). A nebo dá se to řešit na úrovni L2(tam ale si bude muset v nějaké fázi vytáhnout info z vyšších vrstev - například povolit dhcp pouze do té doby než dostane dhcp přidělí IP a dhcp se postará o update pravidla, že odemkne traffic pro tuto MAC)? Nutno myslet, že na jednom portu/wifi rozhraní může být více zařízení(lišíci se MAC adresami)
-
Resil bych to synchronizaci "DHCP leases" (je to nekde ve /var) do firewallu, treba pres inotify a synchronizacni skript. Nebo trocha vice lamersky ctenim logu z dhcpd. Pripadne se podival, zda dhcpd neposkytuje callback/hooky po prideleni adresy. Odmazavani ale bude fungovat na zaklade timeoutu (napr. se muzes ridit podle lease-time).
Na Linuxu je krasny ze si muzes poskladat cokoliv co ty softy nemaj samy o sobe relativne jednoduse.
-
Standardní řešení je "dhcp snooping" and "ip source guard".
https://en.wikipedia.org/wiki/DHCP_snooping
https://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=7
Doporučuju to alepoň zkusit udělat nějak standardně a vyhnout s skriptům které jsou navázané na nějaké inotify na nějakém DHCP serveru, které se potom buhví jak přihlašují na nějaké switche a pouští tam bůhvíjaké commandy.
-
FYI dnsmasq má volbu dhcp-script, není potřeba inotify nebo parsovat logy.
-
Standardní řešení je "dhcp snooping" and "ip source guard".
https://en.wikipedia.org/wiki/DHCP_snooping
https://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=7
Doporučuju to alepoň zkusit udělat nějak standardně a vyhnout s skriptům které jsou navázané na nějaké inotify na nějakém DHCP serveru, které se potom buhví jak přihlašují na nějaké switche a pouští tam bůhvíjaké commandy.
Mimochodem všechno tohle jde snadno obejít odychcením broadcastů, které dnes kdeco vysílá a následně nastavením MAC adresy a IP adresy ze zdrojových zařízení. Samozřejmě tam, kde nebroadcastuje nic má člověk smůlu ale často (minimálně ze zkušenosti) to pro skončí tak, že zmatený switch začne tomu falešnému zařízení normálně doručovat. Jednou jsem takhle víceméně nechtě na nešifrované bezdrátové síti jednoho pražského poskytovatele odchytal bůhvíkolik mailů jejich zákazníků. Kdybych se snažil, určitě bych tam našel i nějaká nezašifrovaná hesla, toho provozu tam bylo fakt dost. Mým cílem ovšem fakt nebylo tu síť cracknout, takže jsem to nějak hlouběji nezkoumal.
-
To na profi webu nikdo nenapíše o reply-only ARP modu, což je prakticky přesně to, na co se ptá? Nedělá to firewall, ale komunikace fungovat nebude.
Ale přijde mi, že si to tady Hamparle plete s Googlem. Vy si myslíte, že ta osoba není Pivotal?
-
Díky oho za nasměrování i za ten arp mód
Nevěděl jsem jak to googlit, když neznám jak se to jmenuje. Kromě toho když se ptám na use-case, vhodnost a další souvislosti
-
Na MT:
https://i.imgur.com/FWnS8WX.png
-
Standardní řešení je "dhcp snooping" and "ip source guard".
https://en.wikipedia.org/wiki/DHCP_snooping
https://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=7
Doporučuju to alepoň zkusit udělat nějak standardně a vyhnout s skriptům které jsou navázané na nějaké inotify na nějakém DHCP serveru, které se potom buhví jak přihlašují na nějaké switche a pouští tam bůhvíjaké commandy.
A tohle funguje i na PC based routru (coz je jak chapu dotaz), nebo potrebujete k tomu dedikovany drahy switch schopen filtrovani, se zapojenim idealne 1 klient per port?
-
@Hamparle
A nemůžete použít rovnou 802.1X, které je k tomu určené? Přes DHCP to bude vždy nedostatečné z hlediska bezpečnosti a nespolehlivé kvůli tomu, že to musíte vyrobit na koleni.
-
A tohle funguje i na PC based routru (coz je jak chapu dotaz), nebo potrebujete k tomu dedikovany drahy switch schopen filtrovani, se zapojenim idealne 1 klient per port?
Je na to samozřejmě potřeba trochu chytřejší switch ale nastavení je to celkem jednoduchý v rámci možností je to blbuvzdorný. (Narozdíl od toho 802.1x, což je teda výrazně složitější na nastavení i správu). Další věc je že pro WiFi je potřeba mít wireless controller který něco podobného taky umí. To už se to pravda trochu prodražuje.
Na "PC based routeru" nebude pořádně fungovat nic v tomhle ohledu. Pokuď jde jen o to někomu trochu znepříjemnit obcházení DHCP a bezpečnost reálně potřeba řešit není (a ten admin/manager to chápe), tak ok, akorát to nejspíš dopadne jako vždycky když takový skripty patlá někdo kdo tomu pořádně nerozumí.
-
Narozdíl od toho 802.1x, což je teda výrazně složitější na nastavení i správu. alší věc je že pro WiFi je potřeba mít wireless controller který něco podobného taky umí. To už se to pravda trochu prodražuje.
S tím bych nesouhlasil. Stačí obyčejný radius server, a jestli se nepletu, dá se Radius naklikat i do Mikrotika. (Nikdy jsem nezkoušel, mám Radius v rámci AD). WiFi bych taky moc nedramatizoval. Vcelku hojně používané Ubiquity to podporují, a jestli je k dispozici PC, tak kontrolér se dá provozovat velmi jednoduše v rámci existujícího Linuxu.
Proto mi to právě celkově přijde jako jednodušší, než vymýšlet opičárny, postupně řešit jeden problém za druhým a na konci stejně neexistuje možnost, že by to fungovalo dostatečně zabezpečeně.
-
S tím bych nesouhlasil. Stačí obyčejný radius server, a jestli se nepletu, dá se Radius naklikat i do Mikrotika.
Akorát do toho Mikrotika pak musí někdo přepisovat všechny uživatele a mazat je když odejdou z firmy. To je nesmysl, takže je potřeba to napojit na existující řešení jako třeba to AD.
Taky by asi bylo vhodné, když už dělám něco takovýho, aby uvnitř neběželo EAP-MD5, což bude asi znamenat potřebu nějaké správy certifikátu (minimálně na authentikaci toho Radius serveru když už ne klientů).
A ve spoustě případů bude taky potřeba guest VLANa, což nás obloukem vrací zpátky k tomu problému s obcházením DHCP serveru.
-
což bude asi znamenat potřebu nějaké správy certifikátu (minimálně na authentikaci toho Radius serveru když už ne klientů).
Opět, v jednoduchém nastavení bych to neřešil a Radius ověření dal do oddělené VLAN.
-
K čemu dávat Radius serveru vlastní VLAN? Proč ne stejnou, jako ostatní servery? Komunikace s Radiusem je z principu bezpečná a váš přístup naznačuje, že by měl mít vlastní VLAN každý server, což mi přijde dost zvláštní.
což bude asi znamenat potřebu nějaké správy certifikátu (minimálně na authentikaci toho Radius serveru když už ne klientů).
Opět, v jednoduchém nastavení bych to neřešil a Radius ověření dal do oddělené VLAN.
-
M.Š. možná chtěl říci, že switch daný port na základě odpovědi od Radiusu dynamicky strčí do určité VLANy? Celkem běžně použivané, že segmentuji stroje do sítě dle oddělení atd, takže to udělá na základě 802.1x (a je jedno zda na wifi nebo metalický ethernet) a lidi se stroji můžou volně cestovat v rámci vesmíru.
IMHO bych nemíchal 802.1x a DHCP snooping, každý řeší něco jiného. 802.1x nedovolí připojit neautorizované zařízení (nebo ho hodí do nějaké guest VLANy) a DHCP snooping následně hlídá, aby si dovolené zařízení nezměnilo IP na něco jiného, než mu poslal DHCP server. Obvkyle asi oboje používat současně. :-)
DHCP snooping bývá někdy společný s IP gueardem, který hlídá zase statické IP na portu. Pak bývá i oblíbený DHCP guard, který zase hlídá, že blokuje cizí DHCP servery, ať si někdo nespustí svůj falešný. A v telko segmentu zase funkce DHCP helper ve switchi, která přidává do DHCP požadavku doplňující info odkud žádost jde, takže pak přiděluje DHCP server IPčka koncovému zařízení na základě toho, kde je zařízení připojeno a ne MAC adres (takže když si koncák doma vymění router za jiný, tak dostane stejnou IP, protože je to pořád stejná koncová linka).
Pokud mám tupý switch, co nic z toho neumí, pak nezvývají nějaké ty obezličky typu ARP reply na routeru předtím, třeba Mikrotik to má relativně připraveno na toto, takže se dá celkem na pár kliknutí, ale neuhlídám už, kde mi pak klient po těch switchích obvykle cestuje...
-
To na profi webu nikdo nenapíše o reply-only ARP modu, což je prakticky přesně to, na co se ptá? Nedělá to firewall, ale komunikace fungovat nebude.
Ale přijde mi, že si to tady Hamparle plete s Googlem. Vy si myslíte, že ta osoba není Pivotal?
Zajímavá otázka :)
Ale vzhledem k tomu, že jsem hned po prvním přečtení pochopil, na co se ptá, tak bych řekl, že ne...
-
@M_D
Chtěl jsem říct tři různé věci:
1. komunikace s radius serverem je zabezpečená, ale pokud se někdo necítí na to, aby s jistotou udržoval šifrování, certfikáty, ..., pak by měl být prvním krokem i to, že samotné ověřování proti radiusu proběhne v jiné VLAN, než která se přiděluje (ne vždy se to totiž tak praktikuje)
2. 802.1x bych považoval za daleko účinnější první krok, než řešit DHCP snooping. Pokud něčím začít, tak 802.1x a to druhé jako něco navíc. Opačný postup nedává z hlediska bezpečnosti tak velký smysl.
3. pokud mi jde opravdu o bezpečnost, pak investice do switche není stěžejní položka; práce s nastavením a údržbou bezpečnosti je mnohem nákladnější, než nějaká škatule
Z dotazu tazatele jsem nabyl dojmu, že se zaobírá správnou myšlenkou (tj. co chránit), ale tápe v tom, jaké existují metody jak to provést. Přijde mi škoda vymýšlet řešení, které nikdy nemůže dojít k cíli - protože takovou ochranu obejde první geek, který se o to pokusí.
-
Jak běžná je funkce, že síťový prvek (kam se strká kabel do sítě) "nedovolí"* připojit "cizí zařízení"
Já teda nevím, jestli to příliš nezjednodušuji a zda OP má chytrý switch, ale řešil bych to fyzickou bezpečností LAN zásuvek plus nastavit na portu switche ( <- LAN zásuvce) povolenou MAC adresu , pokud nad dírou nemám kontrolu, třeba na chodbě. Pokud někdo nemá kontrolu nad tím “kam se strká kabel” tak je něco špatně a hračičkovánínepomůže. YMMV
-
Sorry , typo
-
Já teda nevím, jestli to příliš nezjednodušuji a zda OP má chytrý switch, ale řešil bych to fyzickou bezpečností LAN zásuvek plus nastavit na portu switche ( <- LAN zásuvce) povolenou MAC adresu , pokud nad dírou nemám kontrolu, třeba na chodbě. Pokud někdo nemá kontrolu nad tím “kam se strká kabel” tak je něco špatně a hračičkovánínepomůže. YMMV
Já k tomu doplním, že na switchích lze i nastavit např. to, že MAC adresa nemusí být dopředu nastavená, ale učí se dynamicky a povolí např. jen jednu změnu za den (nebo jiný časový rámec) a při porušení pravidel může dojít buďto k dočasnému nebo trvalému vypnutí portu + report přes AAA. To je takový dobrý kompromis mezi fyzickou bezpečností a snadnou spravovatelností.
-
S tím bych nesouhlasil. Stačí obyčejný radius server, a jestli se nepletu, dá se Radius naklikat i do Mikrotika.
Akorát do toho Mikrotika pak musí někdo přepisovat všechny uživatele a mazat je když odejdou z firmy. To je nesmysl, takže je potřeba to napojit na existující řešení jako třeba to AD.
Taky by asi bylo vhodné, když už dělám něco takovýho, aby uvnitř neběželo EAP-MD5, což bude asi znamenat potřebu nějaké správy certifikátu (minimálně na authentikaci toho Radius serveru když už ne klientů).
A ve spoustě případů bude taky potřeba guest VLANa, což nás obloukem vrací zpátky k tomu problému s obcházením DHCP serveru.
Pokial sa jedna o firmu, tak ta urcite ma LDAP server, na ktorom ma evidovanych vsetkych zamestnancov. A ten ma prepojeny na radius, cez ktory deleguje pristupy a opravnenia. A zaroven aj loguje aktivitu uzivatelov.
Radius sa da vyuzit roznymi sposobmi a hlavne sa da nastavit napr. overovanie menom heslom a az potom dhcp prideli ip, ked overi login a zaroven moze overovat aj mac adresu klienta. Radius vie mat data v mysql tabulke, takze nie je problem si k tomu spravit barz jaky web gui na spravu uzivatelov... Raketovu vedu by som s toho urcite nerobil. Existuju aj hotove riesenia na spravu radiusu...
-
Já teda nevím, jestli to příliš nezjednodušuji a zda OP má chytrý switch, ale řešil bych to fyzickou bezpečností LAN zásuvek plus nastavit na portu switche ( <- LAN zásuvce) povolenou MAC adresu , pokud nad dírou nemám kontrolu, třeba na chodbě. Pokud někdo nemá kontrolu nad tím “kam se strká kabel” tak je něco špatně a hračičkovánínepomůže. YMMV
Já k tomu doplním, že na switchích lze i nastavit např. to, že MAC adresa nemusí být dopředu nastavená, ale učí se dynamicky a povolí např. jen jednu změnu za den (nebo jiný časový rámec) a při porušení pravidel může dojít buďto k dočasnému nebo trvalému vypnutí portu + report přes AAA. To je takový dobrý kompromis mezi fyzickou bezpečností a snadnou spravovatelností.
Jasně, diky za doplneni