Filtrování IP provozu na základě DHCP (povolit těm co si prošli DHCP)

[Hamparle]

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)

[Reklama]

[RDa]

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.

[oho]

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.

[_Jenda]

FYI dnsmasq má volbu dhcp-script, není potřeba inotify nebo parsovat logy.

[Martin Poljak]

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.

[Reklama]

[veskotskujehnusne]

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?

[Hamparle]

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

[veskotskujehnusne]

Na MT:
https://i.imgur.com/FWnS8WX.png

[RDa]

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?

[Miroslav Šilhavý]

@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.

[oho]

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í.

[Miroslav Šilhavý]

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ě.

[oho]

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.

[Miroslav Šilhavý]

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.

[veskotskujehnusne]

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.