A PfSense tűzfalmegoldásokkal kapcsolatos cikk kiegészítéseként szerepeljen itt ez a rövid esettanulmány gyűjtemény, a benne szereplő cégek megnevezése nélkül, a kialakított infrastruktúrák főbb jellemzőivel.
Egy igazi nagyvállalati infrastruktúra
Kezdjük mindjárt a legnagyobb művünkkel. 2017. végén kaptunk megbízást egy vidéki cégtől, hogy megoldást találjunk a szerver rendszerük gondjaira. Egy hatalmas projekt részeként egy komoly nagykapacitású Dell szervert vásároltak, ami a vidéki internet sávszélességek miatt egy budai szerver parkba került elhelyezésre. Itt alakítottuk ki a központi szerver rendszert, tartományvezérlőt és fájl szervert, SAP adatbázis szervert és egy terminal server kiszolgálót (RDS-t), aminek eléréséhez elengedhetetlen volt egy nagy megbízhatóságú és magas biztonsági szintet nyújtó tűzfal megoldás. A választás ezúttal is a PfSense-re esett, a pesti központban szorítottunk neki helyet a nagy Dell szerveren virtuális gép formájában, ami Hyper-V alapokon fut immáron közel másfél éve, megbízhatóan. A központi telephelyre aztán IPSec alapú site-to-site VPN megoldással összekapcsoltuk a hálózatokat, így elérhetővé vált a címtár, az SAP és néhány tűzfalas trükknek, illetve DNS beállításnak köszönhetően a terminal server szolgáltatásait is kizárólag az IPSec kapcsolaton keresztül érik el. A rendszerbe becsatlakozó bolt hálózat mind a 4 telephelyére beszerzésre került egy Dell Optiplex desktop gép, új i3-as processzorral (a hardveres kriptográfiai képességei miatt), 4GB memóriával és az elérhető legkisebb, 500GB-os merevlemezzel. A központban gigabites sávszélesség áll rendelkezésre, a telephelyeken jellemzően 20-50MBit közötti kapcsolatok, így a központi tűzfal és a telephelyeken lévők is megbírkóznak a legmagasabb AES típusú titkosítás mellett is a feladatokkal. Mivel egy telephely kivételével (ahol a másodlagos domain controller lakik) nem áll rendelkezésre a címtár, ezért az üzletek telephelyein különféle DNS trükköket (feltételes továbbítás, host és domain override, stb.) kellett alkalmazni, hogy mindenhol működőképes legyen a tartományi bejelentkezés.
A második legnagyobb
Nemrégiben kaptunk felkérést szintén egy nagyobb vidéki cégünktől, ahol a rekord 640 napos uptime-mal rendelkező tűzfalunk üzemelt eddig, hogy építsünk nekik valami hasonlót, mint a másik ügyfélnél, mert több telephelyes céggé alakulnak. A megoldásuk nagyon hasonló a másik vidéki cégéhez, egy pesti szerver parkban elhelyezett gépen virtualizálva található meg a központi PfSense rendszer, ahova a többi telephely tűzfalai csatlakoznak be IPSec megoldással, a központban lévő szerverek pedig szintén egy virtuális Hyper-V LAN-on találhatóak, ahol csak a PfSense tűzfalon keresztül lehet őket elérni. Emellett náluk még jelen van kétféle OpenVPN konfiguráció is, illetve a másik cikkben már részletezett geográfiai szűréseket is alkalmazzuk.
Tűzfal URL szűréssel
Egyik ügyfelünknél a már megszokott geográfiai szűrés mellett szerették volna a felhasználók gépein a netezést is szigorítani, letiltani például a közösségi oldalakat és egyéb nem kívánatos szolgáltatásokat. Mivel már korábban is fix IP-vel rendelkeztek a hálózaton a gépek, ezért a squid+squidguard csomagok használata mellett döntöttünk, amivel egy transzparens proxy megoldást alkottunk. Ezen beállításra került egy VIP és egy nem VIP csoport, amikbe belepakoltuk a fix IP címeket és ez alapján legyártottuk az ügyfél kérésére az URL szűrési szabályokat.
Vidéki önkormányzat törvényi megfeleléssel
Egy vidéki hivatalban a korábban kiadott törvényi előírásoknak megfelelően kellett kialakítani a hálózat biztonságát. Természetesen a PfSense rendszer tudásában minden szigorú feltételnek meg tudott felelni, még ha nem kevés munkaidőt is igényelt egy ilyen bonyolult rendszer kialakítása. Köszönhetően a számos VLAN-nak, a nagyon szigorú tűzfalszabályoknak, a Radius-alapú WIFI hálózat követelményeinek, a pluszban beszerelt 4db hálózati kártyán futó összesen kb. 8 hálózati szegmensnek.
Komoly OpenVPN szerver hardveres tűzfal mellett
Szintén egy vidéki ügyfelünknél került beüzemelésre egy komoly titkosítással bíró OpenVPN szerver, ahol a PfSense Hyper-V virtuális gépként fut, rajta összesen 5db VPN konfigurációval. Ezek közül 2 a régi mobileszközök komptibilitásának biztosítására lazább titkosítással, helyi adatbázisból történő hitelesítéssel működik. A másik 3 esetében LDAP alapú hitelesítést alkalmaztunk, ahol az Active Directory címtárban lévő különböző biztonsági csoportok tagsága alapján dönti el a rendszer egy-egy felhasználóról, hogy engedélyezi-e számára a hálózathoz való hozzáférést. A csatlakozást követően mind az 5 OpenVPN elérés esetében külön hálózati szegmenseket hoztunk létre, amelyekből a forgalom korlátozásra került, aszerint hogy melyik hálózatból érkezik a kliens csak a neki szükséges szervereket és portokat éri el.
A legtöbb ügyfelünk tehát sima csomagszűrő tűzfalként, vagy OpenVPN szerverként használja ezt a megoldást, ugyanakkor a fentiekből is látszik, hogy komoly, nagyvállalati megoldásokat is lehet belőle építeni némi szaktudás birtokában. Gyakran felesleges pénzkidobás megvenni a méregdrága nagyvállalati megoldásokat, mert a szükséges vagy a használandó szolgáltatások ugyanolyan minőségben elérhetőek ingyenes, Unix alapú tűzfalrendszereken is. Forduljon hozzánk bizalommal hogyha olcsó, de megbízható és biztonságos megoldásra vágyik vagy csak szeretné cégének megtalálni a legoptimálisabb megoldást.
Jelenlegi cikkemet annak apropóján írom, hogy nemrégiben egy ügyfelünknél hatalmas szerveres fejlesztési munkákat végeztünk el, ennek részeként pedig a 2017. májusában beüzemelt tűzfalukat időszerű volt már frissítenünk. Ritkaság ilyet látni, hogy egy rendszer ilyen stabil legyen, a 640 napja egy vidéki ügyfélnél hagyott linuxos (FreeBSD alapú) tűzfalrendszerünk, ami nagyon sok ügyfélnél bizonyított és bizonyít jelen pillanatban is egyetlen újraindítás nélkül élt meg közel 2 évet! Számos konfigurációs feladat merült fel rajta az elmúlt 2 évben, de ezeket mindet átvészelte újraindítás nélkül, ami hatalmas teljesítmény a 21. század hardver és szoftver hibákkal tarkított mindennapjaiban.
Természetesen hiába a linuxos alaprendszer híres megbízhatósága, ehhez a teljesítményhez megbízható hardver megoldás is kellett. Jelen esetben egy belépőszintű, gyakorlatilag a desktop gépek kategóriájához sorolható Dell PowerEdge T20-as szerver adta a „vasat” a rendszer alá, amely korábban szerverként már néhány évet üzemelt náluk, így legalább akkora dícséret illeti ezért, amekkora a rajta futó tűzfalrendszert.
Nagyon sok ilyen tűzfal gépünk fut kint jelenleg is ügyfeleknél, ezekhez nagyon sok esetben vagy egy ügyfél által korábban kiselejtezett, de még megbízható gépet használtunk, vagy egy megbízható brand desktop gépet (Dell vagy HP) rendeltünk számukra két (vagy több) hálózati kártyával. Erre kerül rá aztán a sokak számára ismerősen hangzó PfSense alaprendszer, amihez társul 25 év szakmai tapasztalata és a végeredmény egy 20-25 ezer forintból felépülő vállalati tűzfalmegoldás, ami tudásában még nagyobb vállalatoknak is megfelelő választás lehet. Néhány kompromisszummal még a nagy IT biztonsági multik által kínált céleszközök szintjét is el lehet vele érni. Azért csak kompromisszumokkal, mert azért mégis csak egy ingyenes tűzfalrendszer, aminek nyilván vannak gyengéi is, mint például a kliens oldali vírusvédelem hiánya vagy a spam-ek elleni védelemhez, illetve a profi URL szűrésekhez használható tudásbázis, amit a nagy gyártók kemény díjakért kínálnak nekünk készen. Még ez is elérhető itt, de nem annyira profin, nem annyira naprakészen és nem annyira konyhakészen. Emellett egyes gyártók (mint pl. Fortinet vagy Sonicwall) nem Unix alapú rendszerekkel dolgoznak, illetve nem Intel alapú hardvermegoldásokkal, ami szintén szűkíti a támadási lehetőségek körét. Itt jelen esetben a FreeBSD-hez vagyunk kötve, ami abban az esetben lehet érdekes, hogyha az alap operációs rendszer miatt válik valami törhetővé. Ne feledjük azért, hogy a nagy brand gyártók legtöbb terméke (pl. Cisco) is Unix alapokon nyugszik. Így ezek a termékek ugyanúgy tartalmazzák az esetleges Unix sérülékenységeket. A hátrányok ezzel nagyjából el is fogytak, nézzük azt mit tud adni nekünk.
Egyrészt lehetőségünk van vastag VPN (erősen titkosított) megoldások használatára, akár komoly titkosítású OpenVPN szerverről, akár telephelyek közti IPSec-ről legyen szó, de nem kell lemondanunk a különböző malware-ek elleni védelemről sem, mert a feketelista alapú szűrések mellett lehetőségünk van geográfiai alapú IP szűrésre is, de letöltehetőek különböző proxy modulok, vírusvédelem, URL szűrés, vagy éppen behatolás érzékelő rendszerek is. Szinte csak a képzelet szab határt, na meg persze a hardver, az alap modulok használatához ugyanis egy ősrégi PC is elég akár, de ha komoly titkosítással bíró VPN rendszert akarunk üzemeltetni, akkor a sávszélesség, illetve a redundancia igény függvényében akár egész komoly hardverre is szükségünk lehet. Ahogyan a bevezetőből is látszik, ha rászánunk egy kis extra keretet, akkor egy brand szerver segítségével bármelyik nagy gyártó tűzfal megoldásával vetekedő rendszerünk lehet, annak az árnak a töredékéből.
A megfelelő hardver kiválaszása, a szoftver megfelelő telepítése és konfigurálása természetesen nem egyszerű feladat, de kellő tapasztalattal és szakértelemmel bárki számára elérhető megoldás lehet. A korábbi, IT biztonsággal foglalkozó cikkeinkben (Gondolatok az IT biztonságról – Social engineering, Gondolatok az IT biztonságról 2. – egy majdnem bekövetkezett katasztrófa története) mindben szóba került már ez a megoldási alternatíva. Sok cég életében akkor jött el egy ilyen rendszer bevezetésének ötlete, amikor már egy katasztrófán vagy nehéz helyzeten átestek. Érdemes ezt megelőzni és ajánlatot kérni a kialakításra, mert rengeteg bajtól tud minket megóvni.
Milyen egyéb hozzáadott értékeket nyújtunk mi?
Természetesen a felvázolt szerepkörök, a nyújtandó szolgáltatások alapján segítünk kapacitást tervezni és kiválasztani a feladathoz a megfelelő hardvert. A hálózat kialakításnál ezt követően lehetőség szerint két hálózati kártyát (WAN és LAN) használunk, ahol a megfelelő hálózati eszköz ellátottság esetén VLAN-okkal növeljük tovább a biztonságot. A legtöbb tűzfalunkon kialakításra kerül megfelelő titkosítású OpenVPN elérés, illetve adott esetben site-to-site VPN megoldásként IPSec VPN megoldások. Egy külön tűzfalcsomag telepítésével megvalósítjuk a legtöbb helyen a malware szűrést feketelisták alapján, illetve a geográfiai szűrést az ügyféllel egyeztetve. Itt érdemes megállni pár szóra. Ennek a szűrőnek az a lényege, hogy akár országokra bontva tudjuk IP cím alapján korlátozni a bejövő kapcsolatokat. Vannak ún. illegális tevékenységektől erősen fertőzött országok a világban, ha ezek teljes kikapcsolására lehetőségünk van, akkor töredékére tudjuk csökkenteni egy sikeres támadás esélyét. Tehát például ha lekapcsolható teljes Dél-Amerika, Afrika, Oroszország és Ázsia nagy része, akkor ezzel önmagában harmadára szorítottuk vissza a lehetséges támadások számát. Innentől semmilyen hálózati kapcsolatot nem engedélyez a tűzfalunk a hálózatunk irányába. A szabályokat ügyfeleinkkel közösen szoktuk meghozni, mivel ebben az esetben a rendszer távoli elérése sem lesz lehetséges később ezekből az országokból, hacsak az oda utazó felhasználó ezt külön nem kéri az utazás előtt.
PfSense tűzfalrendszer virtuális gépen? Miért ne?
Ugyan sokan félnek ettől a fajta kialakítástól, de nem kell. Több ügyfelünknél évek óta futnak Microsoft Hyper-V alapú virtualizáció segítségével ilyen tűzfal gépek, amelyekre ugyanúgy igaz, hogy sosem kell őket újraindítani, csak ha nagy release frissítést végzünk rajta. Ez esetben viszont hardvert sem kell külön vásárolni a célra, mindössze szorítani neki helyet egy nagyobb „vason”.
Tűzfalrendszereinket rengetegen használják a legkülönbözőbb feladatokra, a legösszetettebbtől az egyszerű csomagszűrésig. A legtöbb ilyen tűzfalunkról, a cégek megnevezése nélkül ebben az esettanulmányunkban olvashat részleteket.
A „Gondolatok az IT biztonságról” című cikk folytatásaként most ismét zsarolóvírus témával jelentkezünk, ezúttal ismét egy kicsit más incidenssel kapcsolatban. A tapasztalat még nagyon friss és számtalan tanulsággal szolgál, cégtulajdonosnak, felhasználónak és üzemeltetőnek egyaránt. Ezt a cikket főleg nekik ajánlom, de legfőképpen a cégtulajdonosok figyelmét szeretném vele felhívni, ugyanis a most következő történetből jól látszik majd hogyan kerül veszélybe egy egész cég élete pillanatok alatt. Azok közül pedig akik ezt elolvassák jó eséllyel nagy számban lesznek olyanok, akik legalább ekkora (ha nem nagyobb) veszélynek vannak kitéve jelen pillanatban is, legfeljebb nem tudnak róla.
A most következő történet egy hónapja történt egyik ügyfelünkkel. A probléma alapját a korábbi cikkünkből jól ismert támadási módszer (RDP támadás) jelentette, ami több kisebb-nagyobb hiba együttállásával majdnem katasztrófába torkollott. A cikk végén végigvesszük majd részletesen is ezeket a hibákat és a lehetséges megoldási alternatívákat, megelőzési módszereket is pontokba szedjük, de még mielőtt erre kitérnénk engedjenek meg nekem egy kis kitérőt. Számtalanszor felmerült már az a kérdés, hogy mennyit ér meg nekünk adataink biztonsága. 2019-et írunk, réges-rég az információ korában élünk, adataink a legnagyobb értékeink. Egy cég fennmaradását alapjaiban rengetheti meg, ha nagyobb mennyiségű adatot veszít. A jelenlegi cikkben szereplő cégünk mérnöki tervezéssel foglalkozik, ipari projektekbe tervez 3D-s CAD alkalmazásokkal, mérnökök egész hadát foglalkoztatja, akik szoros határidőkkel készítik el és küldik meg a különböző projektekhez tartozó rajzokat. A projektek elnyerése nem kevés munkával jár, a különböző szabványokhoz mindent alaposan dokumentálni kell, tárolni, meg kell tudni őrizni és a megadott határidőre le kell azt adni. Ebből működik a cég, az ezért járó díjakból fizeti a dolgozóit, családok megélhetése múlik rajta. Aztán bekerül a rendszerbe egy új vírus és mindezeket egy pillanat alatt veszélybe sodorja, mert ha elvesznek az adatok és a cég nem tudja a projektre beküldeni a rajzokat határidőre, munkákat veszít el emiatt, akkor mindez alapjaiban kerül veszélybe. Azért ajánlom most vezetők figyelmébe ezt a cikket, mert a végére mindenki számára világos lesz, hogy vannak hatékony megoldások a kockázatok csökkentésére, a legtöbbje még csak nem is pénz kérdése, de mivel sokan szimplán nem foglalkoznak ezekkel, amíg fájdalmas gyakorlati tapasztalatot nem szereznek, így nagyon sok cég van ezek miatt veszélyben.
A jelen cikkben szereplő partnerünknél 4-5 évvel ezelőtt telepítettünk egy kisvállalati Windows Server-t, ami az Essentials változatnak megfelelően tartományvezérlő, fájl szerver, WSUS (frissítés) kiszolgáló szerepköröket lát el, emellett a Windows Server biztonsági másolat készítő programját használja, amivel egy különálló (de fizikailag a szerverben lévő) merevlemezre készít mentéseket. A szervert annak idején a megszokott pontossággal, precizitással telepítettük, elkészítettük a rendszer teljes dokumentációját (amit nagyon sok rendszergazda szimplán kifelejt, mi sem szeretünk dokumentációkat írni), a kliens gépeket tartományba léptettük, majd átadtuk az elkészült rendszert a megrendelőnek. A havi átalánydíjas karbantartási szerződés ötlete már ekkor felmerült, de mivel több olyan műszaki beállítottságú ember is volt a cégnél, így végül közülük ketten kaptak rendszergazda jogokat és évekig ellátták a feladatokat. Néha kaptunk megkeresést komolyabb problémák esetén, de a napi feladatokat, a gép esetleges ellenőrzését ők végezték, ha végezték. A kezdetben szereplő két rendszergazda közül valamelyik 2015. októberében létrehozott egy Admin nevű felhasználót, ami nem csak túl általános nevű volt (elsők között fognak a támadók admin és administrator nevű felhasználókra jelszavakat próbálni), de vélhetően nagyon egyszerű jelszóval is lett ellátva, ez adta ugyanis a támadás alapját, a címtár szerint kb. 1300 hibás próbálkozás előzte meg a támadást és a jelszótörő program betalált a szerverre. Mivel az az audit funkció nem volt bekapcsolva a szerveren, ami naplózná a felhasználó létrehozásának körülményeit (bár ez annyira régen volt, hogy amúgy se lenne már meg a napló), így csak az időpontot tudjuk megállapítani. A szervernek évekig nem volt (rendszer)gazdája, míg kb. 1 évvel ezelőtt egy havidíjas szerződéssel megkaptuk az üzemeltetését. Innentől a havi ellenőrzési procedúra részévé vált a szerverük ellenőrzése, többek közt rendbe lett téve a korábban gyakran hibázó biztonsági mentés is. Egy dolog viszont nem volt az ellenőrzési procedúra része, mégpedig, hogy a különböző felhasználók adminisztrátori jogait nézegessük, az igazat megvallva nem is voltunk ehhez hozzászokva, hogy utólagosan vegyünk át egy már ismert, de jelentősen megváltozott rendszert, pláne olyan bújtatott felhasználókkal, amikkel egyébként már korábban is feltörték a szervert. Ennek nyomait találtuk ugyanis több helyen a gépen, egy időben (2015 őszén és 2016 tavaszán) 2 alkalommal is spamküldésre használták fel, mígnem 2019. február elején egy másik próbálkozás ismét betalált a könnyen támadható „admin” felhasználón keresztül.
Természetesen a problémából mi is levontuk a következtetéseket és a szerver karbantartási procedúra részévé tettük a jogosultság ellenőrzést, ami nem egyszerű feladat egyébként. Ezen kívül minden olyan általunk üzemeltetett szerveren, ahol rajtunk kívül másnak is rendszergazda joga van bevezettük a címtárnak azt az audit házirendjét, ami naplózza az új felhasználók létrehozását és a jogadásokat. Mivel ez a biztonsági napló része, ami rengeteg bejegyzést tartalmaz, így rövid időn belül felülíródik, ugyanakkor 1-2 héten belül így is lehetőség van visszanézni ki mit csinált a szerveren. Ezt kiegészítettük egy saját készítésű Powershell scripttel, ami minden este megvizsgálja a főbb rendszergazda csoportokat és ha bármelyik tagságában változás áll fenn értesítést küld. Ezt a két intézkedést kombinálva a jövőben meg tudjuk előzni a felesleges, kontroll nélkül rendszergazdai jogosultságokból eredő problémákat.
A történet vége szerencsére happy end lett, egyik nap délután 2-kor leállt a rendszerük, addigra szinte minden fájlt titkosított a szerveren a vírus. Másnap reggel munkakezdéskor visszakapták az előző nap hajnalban készült biztonsági mentésből teljesen visszaállított gépet. A gép olyan szinten vírusozódott be, hogy a Windows is romba dőlt, így a rendszerpartíciókat a kb. 1TB adatot tartalmazó adatpartícióval együtt kellett poraiból feltámasztani. Mivel egy olyan friss vírust kaptak, amire nem áll rendelkezésre decryptor (a titkosított fájlok visszafejtését elvégző) program, így a délelőtt folyamán keletkezett néhány fájl elveszett, ami nagyon minimális adatvesztésnek tekinthető, ugyanis a támadáskor éppen megnyitottakhoz nem fért a vírus hozzá, így azok épek maradtak, a biztonsági mentésből történt visszaállítást követően ezeket is visszamásoltuk az ügyfélnek. Így az éppen határidős projektjük legtöbb fájlja megvolt, amin az egész cég dolgozott és egy nagyon veszélyes kriptóvírus támadást sikerült átvészelniük anyagi kár nélkül.
Okos ember viszont más kárából tanul, ahogy a bevezetőben is ígértem térjünk is rá arra, hogy mivel lett volna csökkenthető vagy megelőzhető ez az incidens.
Rendszergazdai jogosultságok Ahogyan arra egy korábbi eset is rávilágított sok esetben akár programok telepítői is gyanútlanul nyithatnak réseket a gépünkre, amikor (sokszor felesleges) rendszergazdai jogot adnak egy felhasználónak a gépre, pláne amikor ezt könnyen kitalálható, netalán közismert, fix jelszóval teszik. Ezeknek a jogosultság adásoknak a felülvizsgálata sajnos rendszeres karbantartási feladat kell legyen, ezzel együtt, ahogyan azt feljebb már említettem script segítségével automatizálva is lehet ezt figyelni. Így időben felfedezésre kerülhetnek a problémák, mielőtt azt mások vennék észre. Az informatikában sokat emlegetett „legkisebb jogosultság elve” (principle of least privilege) pedig érvényes kell legyen a rendszerünkre. Tehát minden felhasználónak csak a feladata ellátásához szükséges legalacsonyabb jogosultsága legyen, semmi több. Ez nem csupán bizalmi kérdés egy felhasználóval szemben, de biztonsági követelmény is. Ha egy olyan felhasználónál következik be incidens, akinek túl magas joga van a rendszerben az ő jogaival komoly károk keletkezhetnek. Erre is volt már precedens, amikor egy ügyfélnek sorozatosan felhívtuk a figyelmét rá, hogy a nagy közös mappát érdemes lenne a különböző munkakörök szerint szétbontani és korlátozni a jogokat. Egy vírustámadás a teljes adatállományt elintézte, a visszaállítás fél napot vett igénybe. Ekkor a saját hibájából tanulva hallgatott a tanácsra és megvalósítottuk a szabályozásokat. Néhány hónap múlva egy másik dolgozó is vírust kapott, de ekkor már a korábbi incidens kb. 1%-a volt a kár, biztonsági mentésből kevesebb, mint fél óra alatt helyreállt a rend.
Mentés, mentés és mentés Számtalan cikkben foglalkoztunk már a témával, zsarolóvírus támadás esetén nincs más menekülés a teljes katasztrófából, csak egy jól működő biztonsági mentés. Szerencsére, mivel nemrégiben kötött ügyfelünk szerződést, így a havi karbantartás alkalmával megnézzük a mentések állapotát, ami így rendben volt. Korábban gyakran voltak vele fennakadások, de ezeket megoldottuk, így volt lehetőség visszaállítani most belőle az adatokat. Ha nincs szerződés és nem megy a mentés, akkor ezúttal egy teljes adatvesztés lett volna a végeredmény és nincs happy end!
Megfelelő jelszóházirend Jelen esetben a felhasználónév admin volt, ami az ilyen jelszópróbálkozásoknak jó alapot ad. Egyrészt érdemes lehet a rendszergazdai jogosultsággal bíró profiloknál mellőzni az ilyen neveket, mint admin, administrator, root, stb. Másrészt pedig meg kell követelni és kikényszeríteni a bonyolultabb, összetett jelszavak használatát. Ezt sok felhasználó nem szereti, de meg kell érteni, hogy a megfelelő biztonsághoz szükség van egy jó jelszóra. A mi esetünkben egy dologról még nem esett szó, hogy az ügyfélnél az elmúlt évek során a gépeken „elfelejtődött” a tartományi rendszer, ami nem azt jelenti, hogy a gépek felejtettek el tartományban lenni, hanem a folyamatos gépcserék során az új gépek nem lettek beléptetve a tartományba, hanem a felhasználók név/jelszavát tárolták be rájuk, hogy a fájl szervert elérjék. Egyrészt a név/jelszó betárolás sosem szerencsés biztonsági szempontból, bármilyen rendszerről is beszéljünk, de jelen esetben ez azért is jelent problémát, mert a gépeken futó rendszerek így nem kerültek a központi házirendek hatálya alá, ami megkövetelhetné a megfelelő jelszavak használatát, elkerülhető lenne a jelszótárolás és a szerver egyéb más funkciót, mint pl. a központi frissítéskezelés (szintén fontos biztonsági elem!) is használni tudnák. Ezzel szemben a felhasználói igény az, hogy ne is legyen jelszó, a gépre ne kelljen külön belépni. Ez így kényelmes, de ára van, biztonsági kockázatot jelent.
Tűzfal Az internetre kiengedett portokat ha van lehetőségünk tűzfallal védeni, az szintén hatalmas előny lehet az ilyen támadásokkal szemben. Jelen esetben egy néhány ezer forintos router látta el a feladatot, ami lényegében annyit tud csak, hogy a portokat ki lehet nyitni velük és a megfelelő IP címre irányítani a belső hálózaton (NAT-olás), korlátozni viszont a legtöbb ilyen eszköz nem tud. Komolyabb gyártók komolyabb eszközein ugyanakkor már vannak arra is lehetőségek, hogy korlátozzuk egyes portok elérését, méghozzá úgy, hogy eközben mi magunk is el tudjuk érni a szerverünket. A VPN, távoli asztal és az egyéb szerveren futó alkalmazások mind ilyen internet felé nyitott portokat igényelnek, amin sajnos bárki bemehet, a megfelelő név/jelszó birtokában. Lehet kapni több tízezer forinttól a csillagos égig terjedő összegekért neves gyártók profi termékeit, amiket jellemzően a hobbirendszergazdák már beüzemelni sem tudnak, mert komoly szaktudást igényelnek. Sok esetben, nagyvállalati környezetben megvan ezek előnye is, ugyanakkor a kis – és középvállalkozások számára szinte elérhetetlenek, az otthoni felhasználásra gyártott router-ek viszont nem igazán felelnek meg a mai biztonsági elvárásoknak. Éppen ezért ezen ügyfeleinknek egy rendkívül olcsó és könnyen kivitelezhető megoldást szoktunk javasolni, még pedig egy Linux alapú (tehát ingyenes szoftverrel telepített) tűzfal gép személyében. Mindössze egy megbízható, stabil PC kell hozzá minimális hardverrel (a legtöbb esetben egy 5 éves irodai processzor, 2GB memória és 5-10GB-nyi HDD bőven elég) és egy extra hálózati kártyával, amit ha egy használt brand gépből hozunk ki legfeljebb 25 ezer forintból ki lehet alakítani. A telepítése és beállítása természetesen szakértelmet igényel, de kellő rutinnal igen rövid idő alatt elvégezhető, nem kell csillagászati költségekkel számolni munkadíjra sem. Ezzel szemben sok olyan szolgáltatást kaphat meg egy ingyenes rendszertől, amiért a nagy gyártóknál komoly összegeket kell fizetni. Ezek közül talán az egyik legfontosabb, amit alkalmazni szoktunk az a geográfiai alapú (GeoDB) szűrés. Sok esetben nincs szükség az országhatáron kívülről történő elérésre, így a legtöbb ügyfél esetében a Dél-Amerikából, Afrikából, Oroszországból, Kínából és Ázsia legtöbb részéről a teljes bejövő forgalmat tiltani lehet. Egy ilyen szűrés a támadások több, mint 2/3-át alapból kiszűrik, mivel ezek közt szerepelnek a kiberbűnözéssel leginkább fertőzött országok is. Amennyiben levelező rendszer nem üzemel a hálózatban úgy szinte csak Európára lehet korlátozni az elérést. Fontos hangsúlyozni, hogy ilyen esetben se VPN-ezni, se távoli asztalozni nem lehet az adott országból és mivel ingyenes megoldásról, ingyen hozzáférhető adatbázisról beszélünk, amiből a tűzfal a tudást meríti így nagy ritkán előfordulnak hibák emiatt, de ez eltörpül amellett a problémahegy mellett, amitől megóvja a rendszert. A szabályokat pedig bármikor lehet finomítani, ki-be kapcsolni egyes területek elérését.
RDP Defender A távoli asztal elérés védelmére, a bejövő kapcsolatok korlátozására szokták alkalmazni ezt a programot. A lényege, hogy megszünteti a végtelen jelszópróbálkozások és a rengeteg különböző IP címekről jelentkező robotok próbálkozásait azzal, hogy a beállított korlátok alapján bezárja előttük a kaput.
Megfelelő vírusvédelem A szerverre telepített vírusvédelem mindig nehéz kérdés. Elvben, mivel munka nem zajlik a kiszolgálón, így vírusnak sem kellene bejutnia rá, amivel okafogyottá válik a vírusvédelem telepítése. Ezzel szemben a szerverekre telepített védelmek gyakran okoznak fennakadásokat, lassulásokat a szerver gépek életében még akkor is, ha megfelelően konfiguráltuk őket. A gyártó egy esetleges hibája a vírusdefiníciós fájlok frissítésekor hatalmas összeomlást tud eredményezni, mint ahogy sok ilyen elő is fordult már a történelemben. Így mérlegelni kell a kockázatokat és a védelem használatából eredő problémákat, hogy érdemes-e védelmet telepíteni. Az is nagy előnye lehet egy fájl szerverre telepített vírusirtónak, hogy ütemezetten lehet vele ellenőrizni a fájl szerverre felkerülő fájlokat, ami a kliensek biztonságát is nagyban javítja.
Ahogyan az a fentiekből is látszik azért annyira sok befektetést sem munkaórákban, sem költségben nem igényel, hogy drasztikusan tudjuk javítani a rendszerünk biztonságát. Azt a rendszerünkét, aminek egy apróbb gyengesége is a cégünk életébe, emberek megélhetésébe kerülhet. Következő cikkünkben bemutatjuk majd azt a tűzfalmegoldást, ami ingyenes és mind stabilitásban, mind tudásban fillérekből tud nekünk olyan nagyvállalati szintű megoldást biztosítani, ami mögött már jobban biztonságban érezhetjük magunkat.
A weboldalunkon sütiket használunk a felhasználói élmény fokozása céljából, hogy megjegyezzük a beállításokat és az ismételt megtekintéseket. Az elfogadásra kattintva minden ilyen süti használatát elfogadod.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
