OpenVPN server-bridge + MAC filter

Web, mail, IRC, IM, hálózatok

Sziasztok!

Routolt openvpnről szeretnénk áttérni bridgelt megoldásra, mert elvileg ilyenkor látszódnak a kliens MAC-ek.
Próbálom, de még sem látom. Az auth scriptbe beraktam ezt: (echo "$*" ; export)  >> $STAT_DIR/openvpn_debug.log
Majdnem ugyanazt hozza, mint a routolt megoldásnál. Nincs benne a MAC. A neten IV_HWADDR és client_hw_addr változókról beszélnek, de ilyenek nem jönnek fel.
Olvastam olyat is, hogy az opensource változatban már nincs benne ez a lehetőség.

Használ valaki ilyet?

A cél, hogy a kiadott  vpn certet, usernév-jelszó párost ne lehessen az IT nélkül idegen gépre feltenni és használni. Kézenfekvő megoldásnak tűnt az auth script MAC címmel történő bővítése.
Tekintsünk el a MAC másolástól, ettől egyszerűbb userekről van szó.

Mi lenne a megoldás?

Köszönöm!

-> ez lett a megoldás, ráadásként tun módban is működik. Kliens configba kell tenni: push-peer-info

( Zs | 2022. 10. 10., h – 22:25 )

Az "openvpnről szeretnék áttérni bridgelt megoldásra'"azt jelenti, hogy marad az openvpn, de tun interface és routeolás helyett akarsz tap intefacet és bridget? Megoldható, de azért hasznos lehet pár dolgot átgondolni:

A szerver oldalon ebben az esetben is IP címek lesznek tárolva, a tap interface mac address nem. Ha nincs megadva, akkor a kliens választ egyet random, ha megvan adva, akkor használja azt. A gond annyi, hogy a kliens oldali konfigban van megadva, tehát ha ezzel bármit ki akarsz szűrni, akkor ez így pont nem fog menni. (Ha ccdt használsz (clientconfigdir), akkor ott tán pusholhatsz a kliens felé szerver oldalról is mac address-t. De nem vagyok meggyőzve arról, hogy ez a kliens oldali konfigban nem bírálható felül.)

A bridge miatt a hálózatok egybe nyílnak, így mindemféle forgalom át fog sunnyogni - IPv4, IPv6, AppleTalk, IPX, meg még ki tudja mi minden. És persze a broadcast csomagok sem fognak megállni az openvpnnél...

Egy ideig teszteltem a tap-ot is, elvileg dhcp-t lehetne futtatni vpn szerveren és akkor az osztaná ki az IP-ket MAC alapján, de végül elvetettem az egész tap megoldást. Szerencsére összejött tun-nal is. Köszönöm a gondolataidat. Az utolsó bekezdésed részben valós probléma még. IPv4 default gw a VPN szerver, na de csak IPv4 van a vpn csatornába kergetve. IPv6 ugyanúgy kiszökhet. Cél, hogy a VPN-re csatlakozott felhasználói gépet kontroll alatt tarthassuk net forgalom szintjén.
Ebben további maszírozás kell. Elvileg openvpn csatlakozáskor IPv6 kikapcsolható.

( debtamas88 | 2022. 10. 10., h – 22:40 )

Szia!

A kliensnél a TAP interface MAC-címe random generálódik és semmi köze a fizikai eszköz MAC címéhez.
Inkább tegyél be valami "többfaktoros hitelesítés" megoldást  ( pl.: privacyidea + keycloak ), akkor az eredeti problémára lesz ez megoldás ( MAC címekkel nem kell vesződni ).

Igaz. Szerencsére a push-peer-info sorral felküldi a fizikai kártya MAC címét. Ezzel a jövőben várható gond: egyes oprendszerek már ezt is random változtatják.

A több faktoros hitelesítés részben feltétel (most is 2 van: login+cert), sokkal inkább az eszköz hitelesítés a cél, hogy engedély nélkül ne lehessen idegen gépet meglévő loginnal hálózatba kötni.

"A több faktoros hitelesítés részben feltétel (most is 2 van: login+cert)" - a másikban írtad, hogy a cert mindenkinek közös, úgyhogy azt én nem tekinteném 2 faktornak. 2FA lehet pl. egy USB-s token (Pl. Yubikey), ami idő alapon generál jelszót, és azt kötöd az userhez.

User szempontból nem teljesen 2 faktor, igaz. Abból az elgondolásból az, hogy egy szűk csoport (cég dolgozói) tudnak csak szóba állni a szerverrel, amikor bemutatták az aktuális időszakra vonatkozó certjüket, amit a szerver CA írt alá - akárhogy is, ez egy hitelesítés a szerver felé.

Majd bemondják a nevüket, jelszavukat - második hitelesítés a szerver felé.

Persze lehet, hogy csak játék a szakmai kifejezéseken. Én azért nyugodtabban alszom, hogy a név-jelszó login lehetőségig a nagy Internet népe nem jut el, csak egy engedélyezett szűk csoport.

Felmerült régen, hogy userenként lehetne saját cert, de nem tudom mennyiben növeli a biztonságot. A hitelesítésben a user beazonosítását egyébként is a név-jelszó páros adja, amit SQL-ből kényelmesen lehet kezelni. Statikus cert fájlok userenként nagyobb kényelmetlenségnek tűnt, mint így: egy közös cégre vonatkozó cert.
Össze lehetne kötni auth scriptben, hogy az adott usernek kiadott cert név + login név-jelszó páros együtt adjon érvényes belépést, de nem látom, hol ad pluszt a biztonságban?

Na jó egy eset: kikerül a kulcs egy gépről és nem tudja annak a gép tulajának a vpn loginját, akkor közös kulcsnál tud más user loginnal is próbálkozni. Egyedi kulcsnál meg nem tud. Csak a kulcshoz rendelt login adatokkal, amit nem tud így lyukra fut. Ez az eset lehet, de ha kiderül (ha kiderül), hogy illetéktelen kezekbe került a gép, akkor új global kulcsot adunk ki illetve az érintett laptop tulaj vpn jelszavát megváltoztatjuk.
Ha a kulcsot vitte, idegen gépen próbálkozik a MAC védelem megfogja. Én ezt is egy hitelesítésnek tekintem, még ha statikus is. A gépet hitelesítem, mint jóváhagyott biztonságos gép. Ha ellopták a gépet, a MAC-et töröljük a user alól, az a MAC máshova meg nem érvényes.
Ezt tovább göngyölve: ha a MAC védelem a jövőben is tartható, akkor lopott kulcs+login birtokában sem tud senki belépni nem jóváhagyott gépről.
Ha csak nem gondol arra, hogy itt a surmó IT-sok a MAC-et is nézik, ez már kicsi esély szerintem.

Egyébként gondolkozunk olyan irányon is, hogy openvpn client csatlakozás után futtasson egy scriptet (erre képes), ami különféle gép adatokat begyűjt (cpu, hdd, ram) és ebből összegyúr egy hash-t. Ez a gép lenyomata és feladja csatlakozáskor. Ezt tekintjük gép hitelesítésnek. Ez felvet még azért még pár problémát, nincs még kitaposva.

Egy auditon ezt nem fogadják el 2FA-nak, mert a kettő közül csak az egyik azonosítja az usert.
"kikerül a kulcs egy gépről és nem tudja annak a gép tulajának a vpn loginját," - ha a közös kerül ki (vagy csak egy dolgozó távozik a cégtől(!)), akkor lehet visszavonni a certet, és újat kiadni. Ha per user van cert kiadva, akkor elég csak az adott dolgozó certjét visszavonni - CRL alapján el fogja hajtani a szerver azzal a certtel.

"a MAC védelem megfogja." - Nincs olyan, hogy MAC védelem, maximum MAC-szűrés, amit viszont minimális melóval át lehet verni - ahogy az openvpn kliens által futtatott scriptet is.