Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

ICS biztonsági tanácsok a tömegközlekedési rendszerekkel dolgozók számára

2016. május 14. - icscybersec

A Belden ipari biztonsági témákkal foglalkozó blogjában jelent meg egy cikk, amiben a világ minden részén rohamosan fejlődő és terjeszkedő tömegközlekedési rendszert kiszolgáló ICS rendszerek biztonságát befolyásoló problémákat és ezek negatív hatásait ellensúlyozó tanácsokat szedtek össze.

Az egyik legfontosabb problémaként itt is az ICS rendszerek Ethernet hálózatokkal történő összekötését említik, a szokásos körülmények mentén: növelni kell a teljesítményt és kapacitást, de mindeközben a költségek csökkentése legalább ennyire fontos (ha nem fontosabb), ezért a tömegközlekedést kiszolgáló ICS rendszereknél is egyre jobban terjednek a költséghatékony standard IT technológiák, protokollok és operációs rendszerek, amelyek magukkal hozzák a nyílt interfészeket és standard protokollokat. Ahogy ezeket a technológiákat egyre nagyobb mértékben integrálják a tömegközlekedés irányító és kommunikációs rendszereibe, úgy nőnek azok a kockázatok is, amiket ezeknek a technológiáknak a már ismert, de még nem javított vagy még nem is ismert hibái jelentenek a tömegközlekedés biztonságára nézve.

Felmerülhet a kérdés, hogy a kiberbiztonság jelenthet-e olyan szintű kockázatot, amivel már foglalkozni kell, amikor a tömegközlekedésbe olyan biztonsági (safety) protokollok vannak beépítve évtizedek óta, amik számos esetben sikeresen előztek meg baleseteket és tömegszerencsétlenségeket? Tény, hogy az üzembiztonsági intézkedések a közvetlen kockázatok többségét hatékonyan csökkentik egy elfogadható szintre, azonban a kiberbiztonsági kockázatok nagyobb része nem közvetlenül, jóval inkább közvetett módon jelenik meg a tömegközlekedés ICS rendszerei esetén, különösen, hogy amint ezek az ICS rendszerek egyre összetettebbek lesznek, úgy lesz egyre nehezebb elérni a megbízható üzembiztonsági szintet.

Fontos kiemelni, hogy a kiberbiztonsági kockázatok nem kizárólag az ICS rendszerek biztonságát (safety) befolyásolhatják, hanem lehetőséget kínálnak a teljes ellátási láncra hatást gyakorolni, amelyek gyorsan válhatnak olyan hatássá, amik közvetlenül érintik a tömegközlekedés működését. Például a tartalék alkatrészek késleltetésével el lehet érni, hogy egy vonatot ki kelljen vonni a forgalomból, ezzel befolyásolva a menetrendet (ez Magyarországon nem feltétlenül jelent komoly eseményt, de vannak országok, pl. Japán, ahol még a kisebb késések sem elfogadhatóak) vagy akár a szolgáltatás egészét.

A megnövekedett kiberbiztonsági kockázatok miatt számos ICS biztonsági szabvány született az elmúlt években, amik a tömegközlekedési rendszerek kiberbiztonsági kockázatainak elfogadható mértékűre történő csökkentését célozzák. Ilyen szabvány többek között:

- APTA (American Public Transportation Association);
- Securing Control and Communication Systems in Transit Environments – Part 1;
- RSSB (UK Railway Safety and Standards Board, a railway stakeholder group);
- Rail Cybersecurity Guidance to Industry;
- Transportation Industrial Control System (ICS)Cybersecurity Standards Strategy;
- ENISA Railway;
- ISA/IEC 62443.

Ezek a szabványok számos intézkedést tartalmaznak, amiknek a bevezetése (különösen ICS környezetben) jócskán elhúzódhat, de néhány egyszerűbb, alapvető intézkedéssel jelentős javulást lehet elérni a tömegközlekedésben használt ICS rendszerek biztonságát illetően:

1.) Kockázatelemzés

Minden biztonsági intézkedést célszerű kockázatelemzéssel kezdeni, nincs ez máshogy az ICS rendszerek esetén sem. A hatékony ICS kiberbiztonság megteremtésének alapja, hogy tudjuk, milyen rendszerek, eszközök és folyamatok alkotják az ICS rendszert és értsük ezek funkcióit és üzemszerű működését, ezután lehet elvégzeni a kockázatok értékelését, ami módszertanában nem különbözik bármelyik másik informatikai rendszerrel kapcsolatban végzett kockázatelemzéstől.

2.) Tervezzünk több szintű védelmi stratégiát

A kockázatelemzés után a következő lépés a hálózat biztonságának megtervezése, amiről több szintű (vagy mélységi) védelem (Defense in Depth) néven számos helyen lehet részletekbe menő leírásokat találni. Egy jól tervezett és kialakított több szintű védelmi stratégiának mindenképpen részét képezik az alábbiak:

- Egyetlen ponton elhelyezett biztonsági eszköz/eljárás helyett több rétegbe szervezett eszközök és eljárások;
- A védelem egyes szintjei különbözzenek a többitől, ezzel is nehezítve hogy egy támadó könnyen jusson át a teljes védelmen;
- Az egyes védelmi szintek eltérő fenyegetések ellen legyenek optimalizálva;
- Az azonos biztonsági követelményekkel rendelkező eszközöket tartalmazó zónák biztonsági szintjét az ISA/IEC 62443 szabvány szerint azonos szintűre kell kialakítani.

Helyesen kialakított mélységi védelem egy véletlenszerűen vagy célzottan bekövetkező biztonsági incidens hatásait korlátozni tudja arra a hálózati zónára, ahol az bekövetkezett. Ha mindemellett a megfelelő monitoring rendszer is ki van építve, akkor a megfelelő emberek vagy csoportok rövid időn belül elkezdhetnek dolgozni az incidens minél előbb történő behatárolásán és felszámolásán.

3.) Elsőként a kritikus fontosságú eszközök biztonságát kell megteremteni

A kritikus fontosságúnak tartott eszközöket is priorizálni kell. Például a vasúti személyszállítás esetén az egyik legfontosabb berendezés az az RTU, ami a vasúti jelzőrendszert irányítja, illetve a hálózati infrastruktúra, ami kommunikáció-alapú vonatirányító rendszer (Communications-Based Train Control - CBTC - system) működését biztosítja.

ICS sérülékenységes XXIX

Panasonic FPWIN Pro sérülékenységek

Az ICS-CERT tegnap publikált bejelentése alapján a Panasonic FPWIN Pro PLC programozó szoftverében több hibát talált Steven Seeley biztonsági kutató. A hibák az FPWIN Pro alábbi verzióit érinti:

- FPWIN Pro version 5.x,
- FPWIN Pro version 6.x,
- FPWIN Pro version 7.122 és korábbi verziók

A sérülékenységeket az alábbi hibák okozzák:

- Heap-based buffer overflow
- Access of uninitialized pointer
- Out-of-bounds write
- Type confusion

A fenti sérülékenységeket csak lokálisan és csak felhasználói interakción keresztül lehet kihasználni, ezért mind a négy hiba viszonylag alacsony pontszámot, 4,2-t kapott a CVSSv3 alapján.

A hibákat a gyártó a 7.130-as verzióban javította, az 5.x verziókhoz, mivel már elérték a támogatási időszakuk végét, nem készül javítás, a 6.x verziókhoz pedig csak 2016 szeptemberéig van gyártói támogatás, ezért az ezeket a verziókat használó szervezeteknek a Panasonic azt tanácsolja, hogy frissítsenek újabb (7.x) verzióra.

Az ICS-CERT szokás szerint ad néhány tanácsot, amik alkalmazásával a javítás telepítéséig is csökkenteni lehet a sérülékenységekből származó kockázatokat:

- Ne kattintson kéretlen e-mail-ben érkezett linkre vagy csatolmányra!
- A felhasználók biztonságtudatosságát fejleszteni kell, többek között az e-mail-es csalások, a social engineering és az adathalász támadások témaköreiben.

További részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-131-01

Kutatók PLC-ket célzó férget készítettek

A számítógépes férgek igen hosszú ideje (egyes források szerint 1978 óta) léteznek, azonban az ipari rendszerek speciális komponenseit (PLC-ket, RTU-kat, stb.) nem fertőzték meg (vagy ha igen, akkor erről az érintett rendszerek üzemeltetői mélyen hallgattak). Az idei Black Hat Asia konferencián azonban az OpenSource Security munkatársai (Ralf Spenneberg, Maik Brüggemann és Hendrik Schwartke) egy olyan kísérleti féregről tartottak előadást, amit kifejezetten PLC-környezetben történő terjedésre fejlesztettek ki, egészen pontosan a Siemens SIMATIC S7-1200v3 vezérlőket képes megfertőzni.

A férget PLC-Blaster-nek nevezték el és működése többnyire emlékeztet a hagyományos férgekére. A kutatók legvalószínűbb fertőzési vektorokként a PLC-k gyártóit illetve az eszközök szállítás során történő megfertőzését (itt most mindenki gondoljon példának okáért az NSA TAO által használt módszerekre) tartják. Ha egy, a féreg által megfertőzőtt eszköz bekerül a megfelelő hálózatba, a féreg elkezdi scannelni a hálózatot a 102/tcp portot keresve, ami hasonló eszközök jelenlétére utalhat. Ha olyan PLC-t talál, ami még nincs megfertőzve, a féreg nagyjából 10 másodpercre leállítja a PLC-t, ez idő alatt áttölti a saját kódját, majd újraindítja. A kutatók szerint a féreg a Siemens TIA-Portalt utánozva másolja magát és a SIMATIC S7-1200 CPU szoftverekben a gyártó által 2016. március 14-én publikált javítással foltozott hibát kihasználva tudja fertőzni a PLC-ket.

Az OpenSource Security kutatói itt azonban még nem álltak meg a proof-of-concept féreg fejlesztésével és további funkciókat adtak hozzá, képes Command&Control szerverrel kommunikálni, működhet Socks4 proxy-ként, képes szolgáltatás-megtagadás (DoS) támadást indítani és manipulálni tudja a PLC-ből kimenő adatokat.

További részleteket a kutatásról készített 16 oldalas dokumentum tartalmaz.

Schneider Electric Modicon M580 biztonsági fejlesztések

A Schneider Electric patinás névnek számít az ICS fejlesztők mezőnyében, a DigitalBond tegnap megjelent blogbejegyzése szerint az új Modicon M580 típusú termékük fejlesztése során már bizonyos (vállalati szintű informatikai rendszerek esetében alapvetőnek tekintett) biztonsági fejlesztéseket és teszteléseket is alkalmaztak. Ilyenek például a fuzzing, a biztonságos programozási technikák, biztonságos fejlesztési gyakorlatok, fenyegetés-modellezés, stb. Ezek eredményeképpen a Modicon M580-asok új generációjában az FTP, a TFTP, HTTP, EtherNet/IP, SNMP és DHCP/BOOTP protokollok alapértelmezetten tiltva vannak és a Modbus/TCP protokoltt is ki lehet kapcsolni. Ezzel együtt még mindig vannak régóta ismert problémák az eszközzel, ilyen például a Faulty Device Replacement (FDR) szolgáltatás FTP felhasználója esetén a felhasználónév/jelszó párosának használata. Az FDR felhasználó jogait a gyártó ugyan limitálta a konfigurációs fájlokra, de ez ilyen módon még mindig egy igen súlyos biztonsági probléma forrása lehet.

További újdonság, hogy az M580 kapott egy alapszintű ACL-képességet. Ez leginkább a különböző Layer-3 hálózati eszközök ACL-jeinek megfelelő funkcionalitást jelent, ami azonban mégis előrelépés a korábbi állapothoz képest (különösen, ha már a tűzfallal védett hálózaton belül szeretnénk egyes eszközök további leválasztását megvalósítani).

Ugyancsak elvégezték a nem használt Ethernet portok letiltását, ami ugyan nem világmegváltó újdonság, de jól mutatja, hogy végre hangsúly került az ipari eszközök gyári biztonsági fejlesztésére is. Az eszközbe épített USB port letilthatóságáról egyelőre nincs információ.

Az M580-asokban megvalósították végre a régóta várt biztonsági célú naplózást és az eszköz kézikönyvében segítséget is nyújtanak az M580-asokat is használó ICS rendszerek biztonságával foglalkozó szakembereknek. Lehetőség van továbbá syslog protokollon keresztül távoli logszerverekre (SIEM rendszerekre) továbbítani az M580-asokon keletkező naplóbejegyzéseket.

Tudom, hogy egy fecske nem csinál nyarat, mégis bízom benne, hogy minél több ICS fejlesztő cég fogja követni a Schneider Electric példáját és az ilyen és hasonló fejlesztésekkel legalább egy kicsit könnyebbé fogják tenni az ipari környezetekben működő rendszerek biztonságos működésének megteremtését és fenntartását.

ICS rendszerekhez fejlesztett AV-megoldást jelentett be a Kaspersky

Nem újdonság, hogy a különböző ICS rendszerek biztonsági szempontból meglehetősen gyengén teljesítenek, számos ismert hiba található publikusan is szinte minden ipari rendszerhez és ezek javítása időnként nagyon lassan készül el (a legjobb és igen friss példa erre a Moxa NPort termékcsaládjának több típusát érintő súlyos sérülékenységek, amikre a gyártó néhány hete augusztusra ígért javításokat).

Ezt ismerte fel a Kaspersky is, amely még 2012-ben egy biztonságos(abb) ICS/SCADA rendszerekhez szánt operációs rendszer fejlesztéséről beszélt nemrég pedig kifejezetten ICS rendszerekhez fejlesztett antivirus megoldást jelentett be a Softpedian megjelent hír szerint. A Kaspersky új megoldása, bár nulláról kezdték fejleszteni, konvencionális technológiai megoldásokból építkezik (malware-ek elleni védelem, alkalmazás-kontroll, sérülékenység-elemzés, fájl integritás-ellenőrzés) és kifejezetten ICS/SCADA szerverek, HMI-k, mérnöki munkaállomások, PLC-k és hasonló berendezések számára készült. Az ipari rendszerek sajátos üzemeltetési követelményeinek engedve a rendszer képes un. megfigyelő módban működni, amikor csak detektálja a különböző fenyegetéseket, de az ooperátorokra bízza a döntést, hogy be kell-e avatkozni az adott esetben.

Érdekes kérdés, hogy lesz-e igény egy ilyen termékre az ICS rendszereket üzemeltető vállalatoknál. A Stuxnet nyilvánosságra kerülése után több helyen a hagyományos antivirus/endpoint protection megoldásokat kezdték alkalmazni ICS rendszerek esetében is, hogy ezek milyen hatásfokkal működnek, arról csak elképzeléseink lehetnek (bár azzal kapcsolatban, hogy pl. a PLC-k hány százalékán futhat bármilyen AV-megoldás, nincsenek illúzióim), viszont a Kaspersky Industrial CyberSecurity nevű termékével kapcsolatban máris láttam olyan megjegyzést, hogy "Az én eszközeimen ugyan nem lesz ilyen szoftver, bocs Kaspersky..."

ICS sérülékenységek XXVIII.

Sérülékenységek SIMATIC Communication Processzor modulokban

A Siemens ProductCERT által ma publikált bejelentés alapján frissítések érhetőek el a SIMATIC CP termékcsalád alábbi modelljeihez:

- SIMATIC CP 343-1 Advanced: V3.0.44-nél régebbi firmware-verziók;
- SIMATIC CP 343-1 Lean / CP 343-1: V3.1.1-nél régebbi firmware-verziók;
- SIMATIC TIM 3V-IE / TIM 3V-IE Advanced: V2.6.0-nál régebbi firmware-verziók;
- SIMATIC TIM 3V-IE DNP3: V3.1.0-nál régebbi firmware-verziók;
- SIMATIC TIM 4R-IE: V2.6.0-nál régebbi firmware-verziók;
- SIMATIC TIM 4R-IE DNP3: V3.1.0-nál régebbi firmware-verziók;
- SIMATIC CP 443-1 / CP 443-1 Advanced: V3.2.9-nál régebbi firmware-verziók.

A hibával kapcsolatban az első hírek 2015.11.27-én jelentek meg a Siemens ProductCERT oldalán, ezt december 1-jén követte az ICS-CERT publikációja, a mostani bejelentés a hiba javításáról szól.

A hiba kihasználásával egy támadónak lehetősége nyílhat authentikáció nélkül adminisztratív szintű hozzáférést szerezni a sérülékeny eszközökhöz. A hiba kihasználása hálózaton keresztül távolról is lehetséges (a 102/tcp porton keresztül), de ehhez arra is szükség van, hogy a kommunikációs processzor konfigurációját a megfelelő CPU-n tárolják. A hiba CVSSv2 szerint 7,6 pontot kapott.

A Siemens a hiba javításaként az egyes eszköztípusokon a most elérhetővé tett legújabb firmware-verzióra történő frissítést javasolja.

Átirányítás - SANS ICS Security Blog IV.

ICS rendszerek soros porti adatainak monitorozása

A mai posztot már korábban előkészítettem, aztán a napi rohanásban simán meg is feledkeztem róla, de most rátaláltam és elég érdekesnek tartom, hogy közre is adjam.

A SANS ICS security blog-járól ezúttal Mark Bristow írása ér meg szerintem  több figyelmet. A különböző ICS rendszerek, bár egyre gyakrabban használnak IP-alapú hálózati kommunikációt, mind a mai napig nagyban építenek a soros porton keresztüli adatátvitelre, különösen a különböző (ipari) végponti berendezések környékén. Mostanáig a támadók (ahogy az az utóbbi évek jelentősen ICS kiberbiztonsági incidensei, mint például a BlackEnergy, Havex esetén is látható volt) az esetek döntő többségében az ICS rendszer általános informatikai elemeit vették célba és azok kompromittálásával érték el céljaikat. Ahogy az újabb incidensek után a biztonsági szakemberek ezekre a területekre kezdenek koncentrálni, eljöhet a pillanat, amikor a támadóknak már könnyebb lesz a fizikailag jobban védett és nehezebben hozzáférhető, de egyéb szempontokból könnyebb célpontot jelentő soros porti kommunikációt célba venni.

Mark Bristow blogposztja bemutatja a soros porti kommunikáció monitorozásának nehézségeit és lehetőségeit, majd egy Raspberry PI és egy Y soros porti kábel segítségével be is mutatja, hogyan lehet a soros porti kommunikáció csomagjait egy IP alapú hálózatba kitükrözni, hogy már meglévő eszközökkel integrálva el lehessen végezni a szükséges elemzéseket.

További részleteket a SANS ICS Security Blog-ján lehet olvasni.

További részletek váltak publikussá a Moxa NPort készülékek sérülékenységeivel kapcsolatban

Valamivel több, mint egy hete írtam én is az ICS-CERT bejelentése nyomán a Moxa NPort egyes típusait érintő súlyos hibákról (a jelszó nélküli firmware update szerintem az év eddig legjobbja). A Digital Bond laborjában dolgozó, az NPort hibáját felfedező kutatók április 12-én jelentettek meg részleteket arról, hogy milyen úton jutottak el az általuk felfedezett hibák publikálásáig.

A cikk elérhető a digitalbond.com-on.

Átirányítás - SANS ICS Security Blog III.

A SANS ICS Security blog-ján megjelent az ICS Cross-Industry Learning sorozat harmadik része (a második részről már én is írtam röviden). Ezúttal Jake Brodsky ír hosszabban víziközmű rendszerekben használt ICS/SCADA-król, és ezek sajátosságairól. ICS biztonsági vonatkozásban azokról az esetekről ír, amikor támadók az operátorok által végrehajtott legitim tevékenységeket hajtják végre a rendszerben (replay) és olyan biztonsági intézkedéseket is megemlít, amelyek fejlesztése előremozdíthatja a víziközmű vállalatok ICS/SCADA rendszereinek biztonságát.

Részleteket a SANS ICS Security Blog-jában lehet olvasni.

ICS sérülékenységek XXVII.

Accuenergy Acuvim, Sierra Wireless ACEmanager és Ecava IntegraXor sérülékenységek

Április 14-én ismét mozgalmas napja volt az ICS-CERT-nek, egyetlen nap alatt három, ICS rendszerek sérülékenységeivel kapcsolatos publikációjuk jelent meg, ezek közül kettőt ismét a korábban már többször hivatkozott Maxim Rupp, független kutató fedezett fel.

Sierra Wireless ACEmanager információ-szivárgást lehetővé tevő sérülékenység

A Sierra Wireless ACEmanager egy gateway-berendezés, ami az ipari és vállalati hálózatok között szoktak használni. A hiba az alábbi típusú termékeket és szoftververziókat érinti:

- LS300,
- GX400,
- GX440,
- ES440,
- GX450 és
- ES450, mindegyik esetén a ALEOS 4.4.2 és korábbi verziókkal használva.

A sérülékenységet az érintett eszközökön filteredlogs.txt fájlhoz történő, authentikációt nem igénylő hozzáférés okozza. Mivel ezekat a fájlokat a rendszer-diagnosztikához használják, a támadók ezekhez hozzáférve megismerhetik a gateway-ek karakterisztikáját.

A gyártó weboldalán már elérhető a hibát javító frissítés: http://source.sierrawireless.com/resources/airlink/software_downloads/updating-form-older-version-aleos/

További információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-105-01

Accuenergy Acuvim II Series AXM-NET Module sérülékenységek

14-én két másik, Maxim Rupp által felfedezett sérülékenységet is publikált az ICS-CERT, amik az Accuenergy Acuvim II sorozatú AXM-NET Module-okat érinti. Ezek az eszközök multifunkciós mérőberendezések, amelyek az Acuvim II modul által előállított adatokat webes felületen jelenítik meg. A hibák (az egyik a beépített authentikációs folyamat megkerülését teszi lehetővé, a másik a jelszavak szöveges formában történő tárolásából adódik) az Accuenergy alábbi verzióit érinti:

- Acuvim II, NET Firmware, 3.08-as verzió,
- Acuvim IIR, NET Firmware, 3.08-as verzió.

A gyártó egy (szokásosnak) mondható, kockázatokat csökkentő tanácsokat tartalmazó listát tett elérhetővé a Modbus TCP/IP protokollt használó mérőivel kapcsolatban. kapcsolatban. Ennek főbb pontjai:

- Használjunk tűzfalakat a mérők más rendszerektől történő szeparálására;
- Használjunk authentikációt a mérőkhöz történő hozzáférések esetén (ez mondjuk érdekes tanács egy olyan hiba esetén, ami éppen a beépített authentikációs eljárás megkerülését teszi lehetővé...)
- Használjunk VPN-t a mérők távoli elérése során.

A hibák javításáról az ICS-CERT bejelentésében nincs szó.

Ecava IntegraXor sérülékenységek

A nap utolsó ICS sérülékenységét Marcus Richerson független biztonsági kutató és Steven Seeley, a Source Incite munkatársa találták az Ecava IntegraXor egy olyan programcsomag, amivel webes alapú HMI-ket lehet készíteni ICS/SCADA rendszerekhez. A hibák (amik között bizalmas információk nyílt szöveges továbbítása, Cross-site scripting, nem megfelelő beviteli adat ellenőrzésből származó hibák, nem megfelelő jogosultság-kiosztás és SQL injection egyaránt található) az IntegraXor 5.0 build 4522-nél korábbi verzióit érinti. Súlyosbítja a helyzetet, hogy a hibákat távolról is ki lehet használni és az ICS-CERT információi szerint a hibákra írt exploitok nyilvánosan elérhetőek.

A gyártó a hibákat (egy kivételével) javította az 5.0 build 4522-es verzióban, amit ezen linken keresztül lehet elérni: http://www.integraxor.com/download/beta.msi?5.0.4525.2

Bővebb információt az ICS-CERT illetve az Ecava bejelentéseiben lehet találni.

Az ICS-CERT mindhárom fenti rendszer sérülékenységeivel kapcsolatban a szokásos kockázatcsökkentő intézkedéseket javasolja:

- Minimalizálni kell az ICS rendszerek adminisztratív hozzáférési jogosultságait;
- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak!

süti beállítások módosítása
Mobil