[COVID-19] biztonságos HOME-OFFICE I
Sokként érte a világot a járvány, sokan pánikolnak, hogy elvesztik munkájukat annak következtében, hogy nem tudnak majd bejárni dolgozni. A jelenlegi helyzetben mindenki érintett nincs kivétel. Ahogy látom, Magyarországon ebből a szempontból 4 cég típust lehet megkülönböztetni:
- Melyek digitálisan felkészültek egy ilyen helyzetre
- Melyek ismerik a teendőket és még tudnak gyorsan cselekedni
- Melyek segítséget kérnek abban, hogy vállalatuk működését felkészítsük a távmunkára, amennyire csak lehet
- Melyek nem tudják mihez kezdjenek a kialakult helyzettel
Ezt a bejegyzés sorozatot azoknak ajánlom, akiknek gyorsan kell cselekedni, ki kell alakítani a nem létező HOME-OFFICE stratégiát vagy bővíteni a szerény kapacitásokat.
Fontos, hogy ezt sem szabad ész nélkül csinálni, és beengedni a hálózatba a félvilágot, csak mert válság van. Most is körültekintően kell eljárni a lehetőségeinkhez mérten.
Sajnos vannak még rosszindulatú, támadó jellegű felhasználók, akik a pánikot kihasználva a jelenleginél nagyobb üzleti kárt tudnak okozni a vállalat számára, így a biztonság szintén fontos kritérium a üzleti alkalmazások zavartalan elérése mellett.
Ezeket a témákat szeretném technikai oldalról kifejtetni egy-egy postban.
Biztonságos HOME-OFFICE I. Remote ACCESS VPN ASAv
Nagy- és középvállalatok számára már nem kihívás távelérés biztosítása az IT infrastruktúrához, mert van olyan tűzfal vagy VPN koncentrátor berendezésük vagy alkalmazásuk, amely ki tud szolgálni normál üzletmenet esetén néhány 100, esetleg néhány 1000 felhasználót. (Magyarországi átlagos viszonylatokról van szó.)
Mi a helyzet akkor, ha a néhány 100 felhasználó helyett sokszor száz vagy akár több 1000 létszámra kell bővíteni a kapacitásokat?
Ebben az estben két forgatókönyv a leggyakoribb.
Ha a VPN megoldásunk felhasználóra licencelt, de még a hardver kapacitások bőven adnak tartalékot, akkor jó hírem van, mert sok gyártó, köztük talán elsőnek a cisco, a COVID-19 miatt kialakult helyzetre biztosít ingyen licence bővítési lehetőséget.
Ennek részleteit ezen a linken megtaláljátok:
https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215330-obtaining-an-emergency-covid-19-anyconne.html
Azoknak próbálnék segíteni a bejegyzéssel, akik nincsenek ilyen szerencsés helyzetben és kapacitást kell bővítenünk, vagy a HOME-OFFICE szolgáltatást kell semmiből létrehozniuk.
Az alapfeltevés tehát az, hogy a felhasználó számára biztosítani kell, a biztonságos, titkosított autentikált hozzáférést az infrastruktúrához. Infrastruktúra alatt leginkább azokra az IT erőforrásokra gondolok, amelyeket normál munkavégzés keretein belül is használnak. Sok olyan esetet látni, hogy rendelkezésre álló határvédelmi eszközön ez a funkció nem elérhető, vagy hardver erőforrások nem biztosíthatók hozzá.
Sajnos a fizikai eszköz szállítási idők duplájára nőhetnek a kialakult helyzet miatt, ezért záros határidőn belül új eszközt nem lehet létesíteni.
Milyen gyorsabb megoldások állnak rendelkezésre?
NFV
A megoldás a virtualizációban található, ezúttal a hálózati funkciók virtualizálása (NFV) az, amely segíteni tud nekünk.
NFV referencia architektúra
Van egy bonyolultnak tűnő architektúra, amit ha megépítettünk, akkor helyzeti előnyben vagyunk, ha nem, akkor ne most álljunk neki kialakítani, hanem koncentráljunk az architektúra 2 fontos elemére:
1. NFVIS - Hálózati funkció számára biztosított hardver és szoftver erőforrás - magyarul számítógép, amin hypervisor-t tudunk futtatni, ez lehet meglévő IT virtualizációs platform is.
2. VNF - virtuális hálózati funkció, ami jelen esetben RA-VPN koncentrátor funkciót biztosít.
Mit kell tennem?
Telepítsünk fel, akár egy PC-re - kis vállalatoknál ez jó megoldás - egy vmware esxi (ingyenes, vpshere licence-ért kell fizetni), vagy alakítsunk ki egy linux szerverből kvm (ingyenes, dobozos ingyenes megoldás a proxmox), vagy meglévő windows szerver operációs rendszeren használjuk a hyperv (windows szerver op.rendszer fizetős) virtualizációt.
NFVIS architektúra elemet meg is csináltuk (hurrá), a továbbiakban "csak" annyi a dolgunk, hogy telepítjük a VPN alkalmazást a hypervisor fölé.
Ehhez szeretnék nyújtani némi best practise design-t, és némi gyakorlati támpontot, hogyan is indulhatunk el.
A best practise design-t úgy próbáltam meg felépíteni számotokra, hogy ne függjön a jelenleg használt hypervisor-tól, a telepítést pedig kvm és vmware virtualizációban is igyekszem megmutatni.
WFH design a semmiből
Minden komolyabb, vagy kevésbé komolyabb informatikai infrastruktúrával rendelkező cég számára rendelkezésre áll valamilyen Internet kapcsolat. A szerencsésebbeknek bérelt vonali vagy üzleti Internet előfizetésük van melyhez tartozik egy fix IP cím. A normál lakossági Internet kapcsolattal rendelkező cégek számára sem lehetetlen kialakítani az RA-VPN szolgáltatást, csak bonyolultabb és kevésbé stabil.
A design alapja, hogy a jelenlegi infrastruktúra nem alkalmas RA-VPN kialakítására, így ezt hálózati funkciót ki kell fejleszteni, lehetőleg minimális hardver erőforrás bevonásával.
Értelmezzük az ábrát:
- Remote user - az emberem, aki otthonról fog dolgozni
- Internet - no comment :)
- Határvédelem - ez nem biztos, hogy tűzfal maradjunk annyiban, hogy eszköz amivel az Internetre csatlakozunk
- Intranet L1/L2 Network és az alatta lévő sárga intranet cső jelképezi azokat a hálózati eszközöket (switch-ek), amelyekkel az infrastruktúrámban biztosított a számítógépek, szerverek közti összeköttetés.
- tranzit vlan/subnet - nos az Internet, pontosabban a Határvédelem és a virtuális VPN megoldás közé csinálni kell egy szeparált hálózatot a meglévő infrastruktúránkon. Ez lesz a tranzit VLAN.
- Host - az a szerver, amin rendelkezésre áll valamilyen virtualizáció vagy ki lehet alakítani.
- Hypervisor - virtualizációt biztosító szoftver környezet/operációs rendszer (vmware esxi, kvm, windows hyperV, cisco NFVIS CSP :))
- OUTSIDE vswitch - az virtuális hálózati szegmens, ami a tranzit VLAN-t reprezentálja a hypervisor-on.
- INSIDE-vswitch - a intranet-hez való csatlakozást reprezentálja a hypervisor-on.
- INTRA-PC - olyan belső intranetes gép/alkalmazás, amelyet az emberemnek el kell érnie míg otthon dolgozik.
Hogyan álljunk neki?
Elsősorban, győződjünk meg róla, hogy rendelkezésre áll-e a az infrastruktúrában a virtualizáció, ha igen könnyű dolgunk van, mert csak a megfelelő image-et kell feltelepíteni, és már mehet is az ASAv beállítása. Ha nincs ilyen az infrastruktúránkban, akkor bizony létesíteni kell. A paraméterezése nagyban függ attól, hogy hány felhasználót kell kiszolgálnunk távolról.
Ehhez segítséget kapunk a kapacitás tervezésben a gyártói adatlapokból:
Tehát 50-től 10000-ig 1 virtuális hálózati funkció kialakításával tudunk felhasználókat kiszolgálni, persze én inkább azt javaslom, hogy ne feszegessük ezeket a határokat, továbbá a gyártó által ajánlott virtuális erőforrás beállításokat tekintsük kötelező érvényűnek, különben OUT OF COMPLIANCE hibát kapunk vissza, és fuccs az egésznek.... persze bátran kezdhetjük előröl extra befektetés nélkül csak időt raboltunk a kísérletezgetéssel.
Forti VM esetén így néz ki:
A FortiVM is elindítható eval licenccel, viszont ha az lejár akkor amíg nincs licencelve, nem működnek a funkciók.
Oké meg van a VM és most?
Ha eldöntöttük milyen virtuális megoldást választottunk, akkor a design alapján készítsük elő az infrastruktúrát, jelöljük ki a trazit vlan-t és subnetet pl:vlan 4094 - 172.18.12.0/24
Minek ilyen nagy subnet? Mert lehet több virtuális VPN koncentrátort állítunk be, hogy legyen redundancia, és lehessen a kapcsolatokat loadbalance-olni, ha késöbb igények és feltételek adottak hozzá - természetesen ezt infrastruktúra oldalról is kell biztosítani.
A tranzit vlant mind a fizikai, mind virtuális "világban" alakítsuk ki, majd jelöljük ki a címeket. pl:
Határvédelem:
172.18.12.254/24
vVPN1
172.18.12.1/24
Fontos, hogy a határvédelmi eszközön - ha nem akarunk nagyokat szívni - érdemes egy dedikált publikus IP-t 1:1 NAT-al kiajánlani a vVPN címnek.
Ha paranoiásak vagyunk, akkor egyébként SSL-VPN esetén elegendő csak a https-t forwardolnunk.
Ha az infrastruktúra előkészületekkel elkészültünk, akkor telepítsük az vVPN-t.
A következő lépéseket vmware vcenterben fogom bemutatni.
Gyakorlatilag normál OVF/OVA template deployment-et hajtunk végre:
1. Kiválasztjuk a megfelelő template-t
2. Megadjuk a guest nevét, könyvtár struktúrát, a compute és storage erőforrásokat
3. Kiválasztjuk a telepítendő platformot.
4. Megadjuk a day0 konfigurációt
Érdemes nagy hangsúlyt fektetnünk a day0 konfigra mert, ha minden adatot jól töltünk ki, akkor gyakorlatilag a deployment végével már távolról (pl: ssh-n) csatlakozhatunk is az eszközhöz.
5. Már be is léphetünk az új VPN koncentrátorunkba, és indulhat az integráció!
Az integrációt a design-nak megfelelően végrehajtjuk és voalá, máris tudunk még + 50 - 10000 felhasználóra RA-VPN szolgáltatást biztosítani.
Összegezve az eddigieket
A jelenlegi pandémiás helyzet új kihívások elé állította vállalatokat, vannak akik felkészültek, vannak akik cselekedtek, és sajnos sokan lehetnek még, akik tanácstalanok.
Most azoknak próbálok segíteni.
Sok lehetőség van arra, hogy a nem létező vagy szűkös kapacitásainkat felbővítsük.
Vannak, akik már rendelkeznek virtuális kapacitásokkal, azoknak könnyű a helyzete, akár kevesebb mint 1 nap alatt tudnak létesíteni VPN megoldást.
Sok gyártó rendelkezik virtuális megoldással az ilyen esetekre, a bemutatott példa csak egy a lehetőségek tárházából.
A post sorozat további epizódjaiban szeretnék foglalkozni virtual Fortigate SSL VPN-nel, továbbá megnéznénk egy gyors kvm implementációt is, mivel sokan lehetnek, akiknek ilyen megoldást kell telepíteniük, mert még vagy nem rendelkeznek virtualizáció-val, vagy ezt használják alapjáraton.
Természetesen az authentikációval kapcsolatos lehetőségeket is megvizsgáljuk később.
Addig is kitartást mindenkinek, annak is, aki már HOME-OFFICE-ban tolja!
