VPN–VLAN hozzáférés: előbb a mátrix, aztán a szabályok
Szerepek az egyik oldalon, szolgáltatások a másikon. Öt ellenőrzés homályos VPN–VLAN hozzáférési tervből olyan táblát csinál, amelyet a tűzfal tulajdonosa meg tud valósítani.
Kezdje a mátrixszal, ne a tűzfal szintaxisával. Egy táblát, amelynek egyik oldalán szerepek, a másikon szolgáltatások vannak, átnézhet egy alkalmazás tulajdonosa, megvitathat egy biztonsági tulajdonos, és megvalósíthat az, akinél az átjáró van. Ez az átnézés olcsóbb, mint olyan szabályok hibakeresése, amelyekben senki nem egyezett meg.
Egy óra írás később egy hét szabályrégészettel takarít meg. A terv arról szól, ki melyik szolgáltatást éri el, és éppen ez az a rész, amely túléli az újraszámozást.
1. lépés: nevezze meg a szerepeket a hálózatok előtt
Az emberekkel kezdje, ne a kapcsolóval. Írja fel minden csoportot, amely távolról kapcsolódik, és az egyetlen mondatot, amely leírja, mit tesz az a csoport, például raktári dolgozók, akik készletszinteket olvasnak, vagy egy vállalkozó, aki egy integrációt tart fenn. Ha két csoport azonos hozzáférést kapna, ebből a szempontból egy szerep.
Álljon meg itt, ha egy szerep csak egy szervezeti ábra miatt létezik. A saját szolgáltatásigény nélküli szerep azonos cellák sorává válik, és az azonos sorok arra csábítanak valakit, hogy később a kényelem kedvéért egy egész alhálózatot adjon. Aszerint osszon, amit az emberek tesznek, nem aszerint, ki írja alá a kiadásaikat. Hat szerep általában sok egy kis irodának, a három pedig gyakran megfelelő.
2. lépés: alakítson minden cellát szolgáltatásnyilatkozattá
Egy cella, amelyben „Alkalmazások” áll, nem ellenőrizhető. Egy cella, amelyben „HTTPS az ERP-gazdagéphez a 443-on, a személyzeti poolból” áll, az. Cserélje ki minden hálózatnevet célra, protokollra és portra, majd adja hozzá azt a függőséget, amely nélkül a szolgáltatás nem működik, például a belső feloldót vagy az identitásszolgáltatót.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Az irányoszlop kapja el a legdrágább hibákat. Az engedély a személyzetnek egy alkalmazás megnyitására nem jelenti azt, hogy az alkalmazásszerverek kapcsolatot nyithatnak vissza a személyzet laptopjaira, és az első irányt engedélyező állapotfüggő szabályt gyakran úgy olvassák, mintha a másodikat is engedélyezné.
3. lépés: döntse el, hol lesz az identitásból szabály
Valakinek hitelesített munkamenetet kell olyan szereppé alakítania, amelyet az átjáró kikényszeríthet. A támogatott lehetőségek közé tartozik a hitelesítési háttérrendszer által nyújtott csoportházirend, a megbízható munkamenet-attribútumok vagy a szerepenkénti külön címpoolok. Mindhárom működik; az ügyfél által küldött címke nem. Azt a mechanizmust válassza, amelyet az átjárója dokumentál, nem azt, amelyet egy fórumbejegyzés leír.
Olyan címet kiosztani, amely csak látszik VLAN-hoz tartozónak, ugyanaz a nem-válasz más jelmezben. A Netgate útmutatója az OpenVPN tűzfalszabályaihoz egyértelművé teszi a szétválasztást: engedni, hogy az alagút feljöjjön, más döntés, mint engedni, hogy a forgalom átmenjen rajta.
Jegyezze fel, melyik mechanizmust választotta, és hol van konfigurálva. Amikor egy szerep megváltozik, ez a feljegyzés a különbség egy szerkesztés és a három felületen át tartó keresés között. Azt is megmondja egy ellenőrnek, hol nézzen először.
4. lépés: figyelje a forrás címet, amelyet a cél lát
A továbbítási szabálynak a határon a valódi forráshoz kell illeszkednie. Ha az átjáró a VPN-ügyfeleket a saját címére fordítja, minden alatta lévő tűzfal egyetlen forrást lát, és elveszíti a szerepenkénti döntés képességét. Ha megőrzi az ügyfél címét, a visszaútnak léteznie kell ahhoz a poolhoz.
Tesztelje mindkét irányt, mielőtt megírja a végleges szabályokat, majd jegyezze fel a megfigyelt forrást minden cella mellé. Futtassa ugyanezt az ellenőrzést két különböző szerepből, és hasonlítsa össze az eredményt. Ha mindkettő az átjáró címét mutatja, a szerepek megkülönböztetése már elveszett. Az a mátrix, amely megőrzött címeket feltételez, miközben az átjáró forrásfordítást végez, az első alsó ACL-nél elbukik.
5. lépés: tesztelje minden cellát kiadás előtt
Alakítson minden engedélyezett cellát egy reprezentatív műveletté, minden tiltott cellát pedig negatív esetté. Mindkettőt a tényleges szerepben lévő ügyfélről futtassa, ne az átjáró konzoljáról, mert a konzol megkerüli a tesztelt útvonalat.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Egy negatív eset, amely csatlakozik, lelet, nem véletlen, és a helye a mátrixban sikertelen cellaként van, amíg a szabályt ki nem javítják. Tartsa a teszparancsokat a tábla mellett, hogy a következő bíráló újrafuttassa őket, ahelyett hogy újraépítené az érvelést.
Az elkészült tábla túlél az átjárót, amelyhez írták. A szabályok a firmware-rel és a szállítóval változnak, míg az a sor, amely azt mondja, hogy egy vállalkozó elér egy projektszolgáltatást, addig igaz, amíg az a munka meg nem változik.