Hogyan korlátozzuk a hozzáférést két VPN-nel összekötött iroda között

A telephelyek közötti alagút egyetlen kérdésre válaszol, hogy a két iroda tud-e csomagot cserélni, a fontosat pedig nyitva hagyja: melyik fióktelepi eszköz melyik központi szolgáltatást érheti el. Az alagutat kölcsönös bizalomként kezelni az az út, amelyen egy vendég laptop a pénzügyi kiszolgálóval azonos ösvényre kerül. A megoldás nem egy jobb alagút, hanem egy kifejezett engedélyezési lista, amelyet a visszafejtés után érvényesítenek. Ez az útmutató a listát a meghatározástól a bizonyított elutasításig vezeti.

Ebben a sorrendben dolgozzon, és ne szélesítse az alagút útvonalát, amíg az alábbi házirend-lépések nem teljesülnek.

Írja meg a mátrixot, mielőtt hozzányúlna az átjáróhoz

Egy hasznos sor három dolgot nevez meg: forráscsoportot, célgazdát vagy szolgáltatási hálózatot, valamint azt a protokollt és portot, amelyet az alkalmazás valójában használ. A fióktelep és az adatközpont nem bejegyzés. A privát DNS és a hitelesítési szolgáltatások csak akkor érdemelnek saját sort, ha az alkalmazás nélkülük nem működik.

A forrásokat szerep szerint csoportosítsa, ne az alhálózat kényelme szerint: munkatársak, vendégek, adminisztráció. Amikor mindhárom egy lapos LAN-t oszt meg, az átjáró nem tudja megkülönböztetni őket a hálózati rétegen, ezért az identitáskezelésnek vagy a szegmentálásnak kell előbb jönnie. Ezután írja le a mátrixot, minden sorban tulajdonossal és felülvizsgálati dátummal.

Ott érvényesítse, ahol a csomagokat visszafejtik

Az IKE-t és az ESP-t engedélyező szabályok csak a külső alagutat építik fel. A belső forgalom nyíltan érkezik az alagút interfészére, és ott van az engedélyezési lista helye: továbbítási lánc a visszafejtő eszközön, alapértelmezett eldobás, egy szabály mátrixsoronként. Linuxos átjárókon ez azt jelenti, hogy a továbbítás engedélyezett, és a szűrőszabályok az alagút eszközén vannak, nem a fizikai uplinken, ahogy a strongSwan továbbítási útmutatója kifejti.

A forgalomválasztók útválasztási döntés, nem engedélyezési döntés. Egy széles választó, amely mindkét alhálózatot lefedi, helyes lehet az útválasztáshoz, miközben a tűzfal továbbra is csak TCP 443-at engedélyez egy gazdagéphez. A választó az alagúthoz tárgyalódik, és azt írja le, mi léphet be rajta, nem azt, mit használhat egy adott eszköz. Soha ne szélesítse a tűzfalszabályt azért, mert a választó széles.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

A NAT és az átfedő alhálózatok megváltoztatják a szabályokat

Amikor a fióktelepi átjáró minden gazdagépet egyetlen címre fordít az alagút előtt, minden forrásalapú sor összeomlik abba az egy címbe. Vagy hagyja abba az alagútforgalom fordítását, vagy fogadja el, hogy a szabályoknak másra kell támaszkodniuk, például a fordítás előtt rögzített eredeti forráscímre. A távoli vég ugyanezzel a problémával küzd, mert a célgazdagép a NAT utáni címet látja, nem az eredetit.

Az átfedő tartományok a másik csapda. Két iroda, amely mindkettő 192.168.1.0/24-et használ, nem írható le egyetlen házirendtáblában az egyik oldal leképezése nélkül, a leképezés pedig nem pótolja az ütközésmentes címzést. Javítsa a tervet, mielőtt olyan szabályokat ír, amelyeket később ki kell bontania.

Bizonyítson elutasítást, ne csak sikert

Csak az engedélyezett alkalmazás tesztelése nagyon keveset bizonyít, mert egy megengedő szabály valahol feljebb ugyanazt az eredményt adja.

Egy közönséges fióktelepi eszközről érje el a szánt szolgáltatást, és erősítse meg, hogy a teljes munkamenet működik. Ezután próbáljon ki egy célt, amelynek zárva kell maradnia, például egy adminisztratív portot olyan kiszolgálón, amelyhez a fióktelepnek semmi köze, és olvassa le a számlálót vagy a naplóbejegyzést, amely eldobta. A szabálykészlet kikapcsolása annak ellenőrzésére, hogy működik-e, érvényteleníti a tesztet, és nyitva hagyja az átjárót, míg nézi.

Tartsa életben a listát

Az alkalmazások mozognak, és a szabály, amely túléli az alkalmazását, lyukká válik, amelynek nincs tulajdonosa. Rögzítse a felülvizsgálati dátumot a sorhoz, és amikor egy szolgáltatás címet vált, ugyanabban a karbantartási lépésben módosítsa a választó hatókörét és a tűzfalszabályt.

A gazdagépszintű korlátozások az alagút mögött is számítanak: a kiszolgáló saját tűzfalának csak a közzétett szolgáltatásra szabad elfogadnia a fióktelep tartományát. Két egyező réteg könnyebben auditálható, mint egyetlen réteg, amelyben teljesen megbíznak.