Tűzfalak evolúciója. Fehér Könyv (technikai)

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "Tűzfalak evolúciója. Fehér Könyv (technikai) www.balabit.hu"

Átírás

1 Fehér Könyv (technikai) Tűzfalak evolúciója Kivonat: A tanulmány részletesen bemutatja a hálózati határvédelmi eszközök történetét a kezdetektől egészen a napjainkban elterjedőben lévő fejlett megoldásokig. Készítette: Illés Márton, Bánfi Tamás Verzió: 1.0 Dátum: BalaBit IT Security

2 Tűzfalak evolúciója Mi is a tűzfal? A határvédelmi termékek iránt megnövekedett igény következtében számos termék - régi és új - található a piacon. Ezek célközönsége igen változatos, a személyes tűzfaltól (personal firewall), a több ezer alkalmazottal dolgozó cégek védelmére szánt szoftverekig. Az egyes termékek technikai működése legtöbbször homályos, még tapasztalt szakembereknek is gondot okozhat értékelésük, ha nem kifejezetten IT biztonságtechnikával foglalkoznak. A különböző tűzfal termékek gyakran egymástól teljesen eltérő technológiát használnak, legalább ennyire eltérő jellemzőkkel és képességekkel. Annak érdekében, hogy az eszköz kiválasztása megalapozott legyen, szükséges a cél megfogalmazása és az alkalmazott technológiák ismerete. Az informatikai biztonsághoz meg kell teremteni az adminisztratív szabályzást, meg kell valósítani az informatikai eszközök fizikai védelmét, majd a megfelelő határvédelmi eszközökkel be kell tartatnunk az Informatikai Biztonsági Szabályzat (IBSZ) határpontra vonatkozó rendelkezéseit. Az IBSZ ezen fejezetei szabályozzák a határpontokon keresztül elérhető távoli erőforrások használatát, az ehhez kapcsolódó felhasználói jogosultságok rendszerét, az egyes hálózati protokollokra vonatkozó előírásokat valamint bizonyos logikai szabályokat. A védelem megvalósításának első lépése a védendő hálózat Internettől való szeparálása, és az átjárás szabályainak megvalósítása. Ezt az elvet kiterjeszthetjük, és alkalmazhatjuk belső hálózatunkon is, tűzfallal választva le belső rendszereinket egymástól. Ezt indokolhatja a CSI felmérés is, mely szerint a betörések 60%-80%-a belső segítséggel történik. A tűzfalak fejlődése A hálózatra kötött számítógépek számos visszaélésre adnak lehetőséget, a számítógépeken futó alkalmazásokból, az alkalmazások által használt protokollokból és az emberi gondatlanságból kifolyólag. A kockázat mértéke pedig az ugyanazon hálózatra csatlakozó felhasználók számával arányosan nő. Ennek csökkentésére tett kísérleteket (ideértve a szoftveres és adminisztratív megoldásokat is) többnyire az aktuális problémák elhárítása motiválja, amiből két dolog következik: IT biztonságtechnikában a kockázatot csak minimalizálni lehet, teljesen kiküszöbölni általában nem. az IT security folyamatosan fejlődik. A biztonság nem állapot, hanem folyamat. A biztonság fenntartásához állandó felügyeletre, rendszerfrissítésekre van szükség. 2/13

3 A továbbiakban bemutatásra kerülő egyes technológiák esetében éppen ezért fontos mérlegelni, hogy azok mely kihívásoknak próbálnak megfelelni, technológiailag hogyan illeszthetőek a mai kor követelményeihez. Védelem nélkül Az Internet alapvető szabványait azzal a feltételezéssel tervezték, hogy a hálózatba kizárólag jóindulatú, intézményi felhasználók kapcsolódnak. Ami nem biztonságos, azt egyszerűen nem szabad. Az adminisztratív szabályok betartásáról a hálózatba kapcsolódó intézmények maguk gondoskodnak. Az Internet szabaddá tételével a helyzet alapvetően megváltozott. Gyakorlatilag bárki kapcsolódhatott a hálózathoz, akár más országokból is. A felhasználók érdekazonosságában többé nem lehetett bízni, hiszen konkurens vállalatok és kormányok, valamint ellenőrizetlen magánfelhasználók is a rendszer felhasználói lehettek. Csomagszűrő routerek Az egyik kezdeti probléma az volt az Internettel, hogy a forgalmazott csomagok címzettjei védtelenek a kéretlen küldemények ellen. Az Internetre kapcsolt szerverek minden nekik címzett csomagot megkapnak és feldolgoznak. A szakemberek a routerekben látták a megoldást, mivel ezek azok a hálózati eszközök, melyeken egyébként is keresztül haladt a teljes forgalom. A routerek a hálózatok bejáratánál állnak, így ezen az egy ponton a teljes átmenő forgalom ellenőrizhető. A routerek - amik addig csak a csomagok célba juttatásáért voltak felelősek - új feladatot kaptak tehát: adott szabályok alapján egyes csomagokat engedjenek át, míg másokat dobjanak el. A döntéseket az úgynevezett csomagszűrő routerek - vagy csomagszűrő tűzfalak - a továbbítani kívánt csomag fejlécében található adatok és a beprogramozott szabályok összehasonlítása alapján hozzák meg. A csomagszűrő routerek jelentették a legelső lépést a tűzfalak kialakulásában, melyekkel párhuzamosan jelent meg a bastion host, megteremtve ezzel a később kialakult csomagszűrő - alkalmazás szintű tűzfal kettősségét. Az igény az Internet szűrésmentes világának biztonságosabbá tétele volt. A routerek jó megoldási alternatívát jelentettek, mivel a hálózati forgalom mindenképpen rajtuk keresztül haladt. Új feladatot kaptak tehát a routerek, amik eddig csak a csomagok célba juttatásáért voltak felelősek: adott szabályok alapján egyes csomagokat engedjenek át, míg másokat dobjanak el. A döntéseket ezek az úgynevezett csomagszűrő routerek - vagy csomagszűrő tűzfalak - a továbbítani kívánt csomag fejlécében található adatok, valamint az előre beprogramozott szabályok alapján hozzák. A csomag vizsgálatánál csak a csomagok fejlécét vizsgálják meg, a magasabb rétegeket (alkalmazási réteg) adatnak tekintik, és nem foglalkoznak vele. A csomagszűrők a fejlécet azonban különböző szinten vizsgálják. Az IP szint minden esetben kiértékelésre kerül, azaz a döntést befolyásolja a csomag forrás és cél címe, esetleges fragmentálási adatai, illetve ritka esetben még az IP opciók értékei is. A legtöbb implementáció esetében kiértékelésre kerül a következő (adatkapcsolati) réteg is (TCP/UDP). Ezek plusz információt jelentenek a döntési szabályok megfogalmazásakor, lehetőség nyílik a forrás, illetve cél portra való szűrésre, illetve TCP esetén a TCP flagek figyelembe vételére is. 3/13

4 A csomagszűrő tűzfalak döntési mechanizmusa szabálylistákon alapszik. A döntési szabályok (rule-ok) mintákat tartalmaznak, valamint egy döntést. A szabályok egymás után kerülnek kiértékelésre és amennyiben a csomag fejlécéből nyert információk illeszkednek a szabályban megfogalmazott mintákra (forrás cím ill. port, cél cím ill. port), akkor a csomag a szabályban meghatározott döntés értelmében eldobásra, vagy átengedésre kerül. Bizonyos csomagszűrők implementációtól függően lehetőséget biztosítanak a csomag visszautasítására, naplózására, illetve címfordításra (NAT). Az ilyen jellegű feladatok megoldását a csomagszűrők minden esetben modulok segítségével oldják meg, melyek biztosítják számára az adott feladat megvalósításához szükséges állapottartó képességet. (Az állapotkövetés a fent említett NAT - Network Address Translation funkciók ellátásához szükséges.) A csomagszűrők felépítésükből, és működésükből következően nem alkalmasak bonyolult igények implementálására, az átmenő forgalom összetett szűrésére, kapcsolatok követésére. A szabálylisták segítségével leírt policy, azaz szabályrendszer összetett esetekben nagyon nagyra, és ami még rosszabb, átláthatatlanra dagadhat. A csomagok, mint egymástól különálló adatok kerülnek kezelésére, melynek eredményeként nincs lehetőség a TCP kapcsolatok állapotának megbízható nyomon követésére, ami újabb támadási felületet biztosít, illetve megnehezíti a tűzfal adminisztrátorának munkáját az IBSZ-ben definiált szabályok implementálására. Szintén az adminisztrátor lehetőségeit korlátozza a csomagszűrő tűzfalak azon tulajdonsága, hogy kizárólag a csomag fejlécével foglalkoznak, azaz nagyjából a teljes csomag mintegy 3-5%-átveszik figyelembe döntéseik meghozatalánál. Az állapottartás hiánya miatt problémát okoz a csomagszűrő tűzfalak esetén a több porton folyó kommunikáció átengedése, tűzfalazása. Ilyen tipikus - gyakran használt - protokoll például a fájlok átvitelét megvalósító FTP (fájl Transfer Protocol), de számtalan más protokoll is. (SQLNet, H.323, stb) A probléma megoldásához mind a csomagszűrő, mind az állapottartó csomagszűrők kénytelenek több portos kommunikáció esetén beletekinteni az első csatorna adatrészébe is, hogy kinyerjék belőle a második csatorna port számára vonatkozó információt. Bár ez egy lépés az alkalmazás szintű elemzés irányába, tulajdonképpen elemzés az adatrészben nem történik, csupán az adott szolgáltatás kiszolgálásához szükséges információk kinyeréséről beszélhetünk. Csomagszűrő tűzfalaknál ebben az esetben is a feladatra speciálisan előkészített modulok nyújtják a megoldást hasonlóan a NAT funkcióknál leírtakhoz. A csomagszűrő tűzfalak lehetőségei korlátoltak, napjainkban egyre ritkábban találunk tisztán csak csomagszűrő technológiát alkalmazó megoldásokat. Az állapottartás kikerülhetetlen voltát mutatja, hogy bizonyos korábban részletezett feladatok egyáltalán nem oldhatóak meg tisztán csomagszűrő technológiával. 4/13

5 Állapottartó csomagszűrő A csomagszűrő routereket gyakorlatilag csupán arra lehetett használni, hogy csomagokat kizárólag a megbízható címtartományokból engedjenek be a saját hálózatukba. Ezzel visszaállt az Internet nagyközönség előtti megnyitását megelőző biztonsági szint, hiszen a kommunikációt újra a megbízható intézményekre korlátozhattuk. Azonban, például a kibontakozóban lévő elektronikus kereskedelem igényeire ez nem jelentett megoldást. Az üzletnek olyan eszközre volt szüksége, ami az ismeretlen szerverekkel történő kommunikációt is képes volt biztonságosabbá tenni. Ehhez első lépésként arra volt szükség, hogy a tűzfal azonosítani tudja a kapcsolat kezdetét és végét, valamint a kettő között zajló adatforgalmat. Ha erre képes, akkor ki tudja szűrni a kapcsolatba nem illő csomagokat, amik potenciálisan veszélyesek. A feladat kizárólag állapottartással oldható meg. Azaz a beérkező csomagokat átmenetileg tárolni kell, amíg a döntéshez elegendő információt össze nem gyűjtötte a tűzfal. A csomagszűrő és az állapottartó csomagszűrők között a vizsgálat mélységében nincs különbség, csupán az abból nyert információ feldolgozásában. Míg az előző egyetlen csomag fejléce alapján hozza meg a döntést, addig az utóbbi magát a kapcsolatot képes vizsgálni ugyancsak a fejlécekre hagyatkozva. A csomagszűrő tűzfalak bizonyos, a technológia leírásuknál taglalt hibák kiküszöbölése okán születettek meg az állapottartó-csomagszűrő tűzfalak. Csomagszűrő testvérükhöz hasonlóan az állapottartók is szabályláncokkal dolgoznak, de jelentős különbségként, már nem csak az adott csomagból nyert információkat használják fel döntéseik meghozatalához, hanem a csomagok közti kapcsolatokat is figyelembe veszik. Ez a plusz kiegészítés alapvetően a kapcsolatorientált protokollok esetén nyújt plusz lehetőségeket, nagyobb biztonságot. Ilyen protokollra tipikus és a leggyakoribb példa a TCP. A TCP protokoll tűzfalazása esetén az állapottartó tűzfalak képesek a TCP kapcsolatok állapotának követésére, azaz képesek megkülönböztetni a kapcsolat kiépülését végző csomagokat (3-way handshake), a kapcsolat kiépülése után adatot közvetítő csomagokat, valamint a kapcsolat megszakítását, lezárását végző csomagokat. A csomagok megkülönböztetése mellet a tűzfal figyelembe veszi, hogy adott csomag csak adott helyen jelenhet meg a kommunikációban. Például adatot tartalmazó csomag nem előzheti meg a kapcsolat kiépülését, és nem érkezhet a kapcsolat lezárását követően sem. A több csatornás, vagy több porton kommunikáló kapcsolatok, protokollok átviteléhez az állapottartó csomagszűrők ugyanazt az elvet alkalmazzák, amit a csomagszűrő tűzfalak is és adatértelmező képességükre is ugyanazon limitációk vonatkoznak. Az állapottartó-csomagszűrők segítségével könnyebbé válik az átmenő forgalom nyomon követése és szűrése. Már nem csak atomi szinten kerülnek ellenőrzésre a csomagok, hanem a kapcsolatok egésze, az azok közti összefüggések alapján van lehetősége a tűzfalnak az ellenőrzésre. Például TCP válaszcsomagok esetén nem csak az ACK flag megléte, vagy hiánya szolgáltat alapot a döntéshez, hanem a teljes TCP kapcsolat nyomon követése (seq-num, ack-num, window size, stb...) adja meg a segítséget a tűzfalnak. Ugyanígy az új kapcsolat kezdeményezése sem csak a SYN flag meglétén múlik. Az állapottartó csomagszűrő tűzfalak tehát jelentős továbblépést jelentenek a klasszikus csomagszűrőkhöz képest. Mindazonáltal megválaszolatlanul maradnak további problémák, melyeket a technológia ez irányú továbbfejlesztésével már nem lehet orvosolni. A csomagszűrés esetén csak a csomag fejlécéből nyert adatok kerülnek vizsgálatra, a csomag további, megközelítőleg 95-97%-át kitevő adatrész értelmezés nélkül jut át a tűzfalon. Ezen a tényen számottevően a kiegészítő modulok léte sem változtat, hiszen ezek feladata nem az applikációs szintű elemzés megvalósítása egy csomagszűrő esetében, hanem egy bizonyos funkcionalitás biztosítása. A probléma megoldására a tűzfalfejlődés másik ágát képviselő úgynevezett applikációs, avagy proxy tűzfalak jelentik a megoldást, melyek fejlődése a csomagszűrő tűzfalakkal egy 5/13

6 időben a bastion host-okkal kezdődött. Bastion Host A tűzfalak fejlődésének korai szakaszában jelentek meg mint a csomagszűrő routerek alternatívái. Igazából nem nevezhetőek - a klasszikus értelemben nevezett - tűzfalnak, mivel nem végeznek szűrést, de ennek ellenére, mint hálózati határvédelmi eszközök funkcionálnak. A bastion hosztok szerver gépek, melyek több felhasználó párhuzamos, távoli munkáját támogatják. A gép mind a védendő hálózat (intranet), mind a publikus hálózat (Internet) felé rendelkezik direkt kapcsolattal. Így abban az esetben, ha a védett hálózatból egy kliens valamilyen erőforrást akar elérni az Interneten, akkor először be kell jelentkeznie a bastion host-ra, majd ott, a kívánt erőforrás elérését biztosító programot elindítania. Bastion host alkalmazása esetén a szűrési lehetőségek kimerülnek a felhasználók hitelesítéséből adódó lehetőségekkel, valamint nehezen érhetőek el kívülről védett zónában lévő erőforrások. Használat szempontjából alapvetően bonyolultabb a bastion host-ok a felhasználók és az adminisztrátorok számára is, biztonsági szempontból pedig problémát jelent, hogy sok felhasználó használja egyszerre ugyanazt az erőforrást. Így az adminisztrátornak nagyon változékony körülmények között kell biztosítania a rendszer működését és az emberi tényező, mint leggyengébb láncszem fokozottan veszélyforrást jelent. Sok hibájuk ellenére a bastion host-ok egy új - a csomagszűrők elvétől merőben eltérő - megközelítést jelentenek a hálózati határvédelem területén. A csomagszűrő és állapottartó csomagszűrő tűzfalak esetében a kliens közvetlenül kapcsolódik a szerverhez, azaz a kliens által küldött csomag változatlan formában jut el a szerverhez. (Természetesen előfordulnak kivételek, mikor a csomag tartalma - jellemzően a fejléce - megváltozik a tűzfalon történő áthaladás folyamán. Ilyen eset például a címfordítás (NAT), ahol a forrás, vagy a cél cím változik meg). Ezzel szemben a bastion host használata esetén már nem egy kapcsolatról beszélünk, a kommunikáció két fázisra oszlik. Az egyik kapcsolat a kliens és a bastion hoszt között, míg a másik a bastion hoszt és a szerver között épül ki. Ez a megoldás - működéséből adódóan lehetetlenné teszi a csomagszintű támadásokat. A közvetlen csomagkapcsolat megszüntetése egy további előnnyel is jár. Az alapvetően kapcsolatorientált protokollok használatánál (mint amilyen a TCP, amit ma az Interneten leginkább használunk), új megközelítés kerülhet előtérbe. Már nem a csomag jelenti az atomi elemet, hanem a kapcsolatra koncentrálva tervezzük, és valósítjuk meg hálózati határvédelmünket. A kapcsolatorientált protokollok esetében a kapcsolat kerüljön előtérbe. Így lehetőség nyílik a csomagszűrők másik nagy hiányosságának - az adat rész ellenőrzés hiányának - pótlására. Ez további eszköz az adminisztrátor kezében az IBSZ betartatására, a biztonság növelésére. Az alkalmazási szint ellenőrzésével lehetőség nyílik az applikációk elleni támadások sikeresebb kivédésére, valamint a több információnak köszönhetően az összetettebb - és az implementációtól függően flexibilisebb - döntések meghozatalára. A fenti, "új megközelítés" előnyeit, a bastion hostok esetében még nincs módunk kihasználni, de utat mutatnak a további fejlődés, fejlesztés felé vezető úton. A bastion hostok másik nagy hátránya, a nehéz kezelhetőségre válaszul született meg a fejlettebb proxy, valamint socks tűzfalak elképzelése, melyek kényelmesebb alternatívát jelentenek. 6/13

7 Socks tűzfalak A Socks tűzfalak talán a tűzfal fejlődés egyik legérdekesebb, de igencsak rövid életű irányát képviselik. Valahol félúton helyezkednek el a csomagszűrő és a proxy megoldások között. Működésük és jellemzőik a "kicsit ilyen is, kicsit nem is" elvet képviselik, azaz kicsit proxyk, de kicsit kevesebbek is, kicsit csomagszűrők, de kicsit többek is, kicsit transzparensek, de kicsit nem is azok. Hogyan működnek a Socks Proxyk? A Socks proxyk működési elve egyszerű: A kliens gépre telepítésre kerül egy program modul, ami minden hálózati kapcsolat kezelését átveszi az eredeti operációs rendszertől. Amikor egy program kapcsolódni akar egy szerverhez, akkor a kapcsolódási kérését a modul kezeli, és a program helyett kapcsolódik az előre beállított SOCKS proxyhoz, majd megadja a proxynak, hogy milyen címre szeretne kapcsolódni. Ezek után a proxy kapcsolódik a kliens program által kijelölt szerverhez. A kapcsolat kiépülése után az adatforgalmat a kliens program a modul segítségével a SOCKS proxyn keresztül a végzi. Ez a megoldás hálózati szempontból nem tekinthető transzparensnek, de a program szempontjából igen, mivel a programon nem kell külön beállításokat elvégezni. (Bizonyos programok natívan támogatják SOCKS proxyk használatát, ilyenkor természetesen a megoldás nem tekinthető transzparensnek.) A SOCKS működési elvéből következik, hogy klasszikus értelemben csomagszűrőnek nem nevezhető, mivel csomagok a kliens és a szerver között nem közlekednek. Azonban nem tekinthetőek a SOCKS tűzfalalak alkalmazásszintű tűzfalnak sem, mivel a forgalom nem alkalmazási szinten kerül szűrésre, hanem csak hálózati szinten. A SOCKS megoldások nagy előnye, hogy nem transzparens mivoltuk ellenére nem igényelnek különlegesen megírt programokat, mivel a legtöbb esetben lehetőség van az operációs rendszerbe beépülő modul alkalmazására. Nagy előnye a SOCKS megoldásoknak, hogy segítségével, az átengedett protokolltól függetlenül lehetőség nyílik az átmenő forgalom tetszőleges authentikálására. Elmondható, hogy a SOCKS tűzfalak bizonyos tekintetben a csomagszűrők fölött, de az alkalmazásszintű tűzfalak alatt helyezkednek el. Nem teljesen transzparens mivoltuk, és limitált magas szintű szűrési képességeik azonban meggátolták széleskörű elterjedését. Alkalmazásszintű, avagy Proxy tűzfalak A proxy tűzfalak jelentik az első jelentős lépcsőfokot a nem csomagszűrő típusú tűzfalak fejlődésében. A proxy-k a bastion host megoldások után jelentek meg azzal a céllal, hogy kiküszöböljék a felhasználók szerverre való bejelentkezésből adódó kényelmetlenségeket, illetve az ebből fakadó veszélyeket. A proxy tűzfalak működési elve nagyon egyszerű. A kliensek és a kiszolgálók között nem épül fel közvetlen kapcsolat, hanem mindketten a tűzfalon futó proxy alkalmazással kommunikálnak. A proxy egyik hálózati csatolójával az ismeretlen hálózat kiszolgálóihoz kapcsolódik, a másikkal pedig a belső hálózatban található kliensekhez. A kapcsolat kettősségéből kifolyólag a proxy tűzfalak minden különösebb beállítás nélkül képesek kivédeni a csomagszintű támadásokat. Bár a proxy-k kifejlesztésében elsősorban használhatósági szempontok jelentették a fő motívumot, a kialakult új architektúra képessé tette a tűzfalakat arra is, hogy alkalmazásszinten ellenőrizzék a rajtuk áthaladó információáramot. A proxy alkalmazások már nem csupán a csomagok fejlécét vizsgálták, hanem azok adatrészébe is belenéztek, és akár módosításokat is végrehajtottak. Már most le kell azonban szögezni, hogy a cél alapvetően nem a mély protokollelemzés volt, így bár architektúrálisan megoldható lett volna, a proxy tűzfalak első generációja nem értelmezte a protokollok összes utasítását, csupán azok elenyésző részét. 7/13

8 Sokszor a proxykat mint web oldalak gyorstárazás (cache) funkciójával ellátott programot említik. Ezeknek a cacheing proxyknak nem céljuk a biztonság növelése, sokkal inkább a web elérések gyorsítása, ami merőben különböző feladat. Ezeket a programokat inkább webcache névvel célszerűbb említeni a fogalomzavar elkerülése érdekében. A hasonló elnevezés egyébként nem véletlen, a két eszköz működése sok hasonlóságot mutat, de a céljuk az, amiben alapvetően eltérnek. Mind a webcache, mind a tűzfalaknál alkalmazott proxy-k kliensek kiszolgálását teszik lehetővé transzparensen, azaz a bastion host technológiánál leírt két kapcsolat felépítésén alapuló kommunikáció egy közös jellemző. A határfelületet tovább mossa, hogy bizonyos webcache megoldások értelmeznek egy-két parancsot adott protokollból. Például webcache megoldások képesek URL filtering-re a HTTP protokollban, vagy értelmezve a get parancs után kapott paramétert (illik-e valamilyen tiltott mintára), vagy egyszerűen mintaillesztéssel megoldva a feladatot. Utóbb csak egy standard weblekérés mintaillesztése történik véletlenszerűen az adatfolyamban. A csomagszűrő és állapottartó csomagszűrő tűzfalak ugyanezen elvek valamelyike alapján oldják meg ezt a feladatot. Alkalmazás szintű proxy-k azonban protokoll értelmezési képességük miatt mindig parancskereséssel kezdik az URL szűrés műveletét. A proxy tűzfalak megjelenése elsődlegesen a bastion hostok kényelmetlen mivoltára vezethető vissza, ezért is logikus, hogy egyik funkciójuk e kényelmetlenség megszüntetésére irányul. Proxy használata esetén is adott tehát egy gép, ami mind a védett, mind a külső hálózathoz dedikált interfészen csatlakozik. A gépen speciális proxy alkalmazások futnak, ezekhez az alkalmazásokhoz kapcsolódnak a kliens gépén futó programok. A kliens program megadja a proxynak (megbízottnak), hogy a külső hálózaton milyen erőforrást akar elérni, a proxy kapcsolódik az erőforráshoz, majd az eredményt továbbítja a kliens számára. Itt már a kapcsolat van a középpontban és így a kommunikációk szűrése magasabb szinten is lehetséges. Mivel minden protokollhoz, külön proxy-ra van szükség, ezért ennek a módszernek a használata esetén rendelkezni kell az összes használni kívánt protokollhoz megfelelő proxyval. Ez nagyszámú protokoll esetén komoly költséget jelenthet. Az előnye a protokollonkénti proxyk alkalmazásának, hogy adott proxyn csak adott protokoll specifikációjának megfelelő kommunikáció folyhat. Sőt implementációtól függően lehetőség van a kommunikáció protokoll szintű szűrésére. Proxyk esetében a teljes kommunikációra rálátása, ellenőrzési és szűrési lehetősége van a tűzfalnak, ezáltal az adminisztrátornak. A proxy tűzfalak esetén nem okoz problémát a több, portot használó protokollok tűzfalazása, mivel az architektúrának köszönhetően a proxy az alkalmazásszintből minden információval rendelkezik az újabb kapcsolatok megnyitásához. A másodlagos csatornán történő kommunikációt a proxy - implementációtól függően - szintén ellenőrzi. Több csatornás kapcsolatok (FTP, SQLNet, stb.) cél, illetve forrás címeinek NATolása sem igényel kiegészítő megoldások alkalmazását. A proxy tűzfalak egyik hátránya, hogy a használni kívánt protokollnak támogatnia kell a proxy-s működést. A ma használt protokollok esetében sajnos ez nem minden esetben megoldott. Éppen ezért az egy csatornás protokollok esetén rendelkezésre áll egy, úgynevezett general, vagy plug proxy, aminek a feladata csak a kapcsolat megfelelő továbbítása. Ezek a plug proxyk nem ellenőrzik az átmenő forgalom adatrészét, feladatuk csak a két szeparált hálózat közötti kommunikáció biztosítása. Biztonság szempontjából annyival nyújtanak többet a csomagszűrőknél, hogy plug proxy használatakor is két kapcsolat épül ki, kizárva ezzel a csomagszintű támadásokat. Transzparens Proxy Tűzfal: A proxy tűzfalak konfigurációs igényeiből fakadó kényelmetlenségnél nagyobb problémát jelent az ennek következtében jelentkező emberi hibaforrás hangsúlyosabb jelenléte. (A túl sok és gyorsan változó konfiguráció, mely beállítása a felhasználók alkalmazásait is érinti vagy 8/13

9 követhetetlenné válik sok felhasználós hálózatokban, vagy egyre lazább, minden körülmények között működő, de túlságosan "nyitott" szabályrendszereket eredményez.) A változásokat tovább sürgette, hogy egyre több olyan protokoll jelent meg, melyek nem voltak felkészítve a proxy-s működésre. A cél tehát a transzparens működés megvalósítása, és a proxy funkciókat nem támogató protokollok kezelése lett. A megoldás adott volt. A tűzfalon - elhelyezkedéséből adódóan - minden forgalom áthalad (a tűzfal, mint a szervezet hálózatának internetes, alapértelmezett átjárójaként szerepel). Ebből adódóan lehetőség van a tűzfalon a csomagszűrőkhöz hasonló funkciókat ellátni. A klienseken semmilyen proxy beállítást nem kell megtenni, azaz a kliensek közvetlenül próbálnak kapcsolódni a szerverhez. A csomagszűrökkel szemben azonban a csomagok nem jutnak át a tűzfalon, hanem a tűzfal a csomagokat, kapcsolatokat - beépített csomagszűrőjének segítségével - "elkapja", és magára irányítja. Az átirányított kapcsolatokat pedig a proxy program fogadja, a nem-transzaparens proxyk működéshez hasonlóan. Természetesen a transzparens proxy használatával is lehetőség van nem tarnszparens működésre. A tarnszparens proxyk tehát transzparenciájuk megvalósítása céljából kiemelten támaszkodnak az alacsonyabb szintű csomagszűrőre. A csomagszűrő és a proxyk megfelelő együttműködése eredményezi a sima proxyknál kényelmesebb használati módot. A transzparens proxyk használatával a felhasználók számára a hálózati erőforrások tűzfalon keresztüli elérése kényelmesebbé válik, adminisztrációja áttekinthetőbb. A proxy tűzfalak megoldást nyújtanak a kliensek kényelmes és biztonságos kiszolgálására, látszólag megoldva a tűzfalak által keltett problémákat. Azonban az újabb protokollok fejlődésének, összetettebbé válásának eredményeként napjainkban egy újabb problémával kellett a tűzfalaknak, és az őket felhasználó szakembereknek szembenézniük. Ez a merőben új probléma, az összetett protokollok kezelésének kérdése. Napról napra több alkalmazás támaszkodik összetett protokollokra, amelyek megfelelő, biztonságos kezelésére, a már meglévő technológiák nem nyújtanak kielégítő megoldást. Ilyen összetett protokollhasználatra jó példa a napjainkban az ebuisness keretében elengedhetetlen HTTPS protokoll, ami egy SSL (titkosítást és authentikációt megvalósító) protokoll és egy HTTP protokoll kombinációjából született meg. A megoldás egy új tűzfaltechnológia megjelenését eredményezte. Moduláris proxy tűzfalak A moduláris proxy tűzfalak megszületése, más tűzfalaktól eltérően, kizárólag a nagyobb biztonság elérése céljából történt meg. A tűzfalak ezen ága nem kényelmi okokból fejlődött ki, a tervezési szempont a megfelelően biztonságos működés elérése volt. A moduláris proxy tűzfalak rendelkeznek a transzparens tűzfalak minden jó tulajdonságával, azaz képesek az átmenő adatfolyam alkalmazásszintű szűrésére, csomagszűrő kiegészítőt tartalmaznak, valamint transzparensek a kliens számára. Az alapvető különbség a hagyományos transzparens tűzfalak és a moduláris tűzfalak között, hogy míg a transzparens tűzfalak minden protokoll értelmezésére, elemzésére különálló tűzfal komponenssel rendelkeznek, amelyek nem képesek együttműködésre, valamint sok esetben bizonyos funkciókat mindegyik komponens megvalósít (kapcsolat fogadása, kapcsolódás a szerverhez, stb.), addig a moduláris proxy részei, moduljai képesek együtt működni, valamint a különböző feladatok ellátását más-más modul végzi, csökkentve ezzel a felesleges redundanciát. Mit is jelent ez konkrétan? A modularitás több szinten valósul, valósulhat meg egy moduláris tűzfalon. A leggyakoribb és általában a legtöbb helyen szereplő példa az egyes proxy modulok együttműködésén alapszik. Ahogy az előzőekben már megemlítésre került, napjainkban egyre több az összetett alkalmazásszintű protokollt használó program, erre a legjobb példa a már említett HTTPS. A HTTPS különlegessége, hogy nem csak összetett protokoll, hanem 9/13

10 az egyik része titkosított, úgynevezett kripto protokoll, amelynek a szűrése, visszafejtése még bonyolultabb. A moduláris proxy esetében egy SSL proxy és egy HTTP proxy kerül kombinálásra. Az SSL proxy kapja meg az átmenő forgalmat, azt dekódolja - azaz a kliens felé mint a szerver jelenik meg, végrehajtva ezzel egy Man-In-The-Middle támadást -, majd a dekódolt forgalmat átadja a HTTP proxynak. A HTTP proxy már a sima HTTP kérést kapja meg, mintha azt egy sima klienstől kapná. A kérés feldolgozása után a HTTP proxy a kérést továbbküldi, mintha a szervernek küldené, de a kérés az SSL proxyhoz kerül, amely a kérést újra titkosítja és elküldi a szervernek. Ezzel a módszerrel lehetőség nyílik a HTTPS forgalom transzparens HTTP szintű szűrésére, amely fontos részét képezheti a trójai programok, valamint más nem kívánt programok elleni védekezésnek. A moduláris tűzfal bizonyos proxy moduljai fel vannak készítve arra, hogy a rajtuk átmenő forgalom egy részét képesek legyenek egy másik proxynak további elemzésre átadni, azaz más elemző proxy modult a bevonni, beágyazni a forgalom elemzésébe. Természetesen, ha egy proxy modul esetén lehetőség van beágyazásra, akkor az bármelyik másik proxy modult képes beágyazni. (Persze elképzelhetőek olyan kombinációk amelyek esetében nincs értelme a beágyazásnak.) Lehetőség van továbbá több szintű beágyazásra is, például SSL proxyba ágyazott HTTP proxyban tartalomszűrésre, ahol a tartalomszűrést egy tartalomszurok modul valósítja meg, vagy SSL proxyba ágyazott POP3 proxyban a letöltendő levelekben víruskeresésre. Látható, hogy a beágyazás segítségével az egyre több kombinált protokoll széles palettájának elemzésére, szűrésére van lehetőség, valamint lehetőség van nem protokoll specifikus modul alkalmazására is. A moduláris tűzfalak másik oldala, amely általában kevésbé kerül előtérbe, ám szintén nagyon fontos, teremt lehetőséget a különleges igények kielégítésére, valamint ez veszi át az egyes proxy moduloktól a közös feladatok ellátását. Ilyen modul például a kapcsolatok fogadásáért, vagy kiépítéséért felelős modul. A proxy moduloknak nem feladata többé a kapcsolatok kezelése, csak azok forgalmának elemzése, szűrése, a kapcsolatok kezelésére külön modulok állnak rendelkezésre. Azaz egy speciális modul feladata a kapcsolatok fogadása, majd kapcsolódás esetén, a megfelelő ellenőrzések után, a kiépült kapcsolatot átadja a proxy modulnak, amely csak a forgalommal foglalkozik. Ugyanígy, ha szükség van a kapcsolat szerver oldali részére, az szükséges új kapcsolat kiépítése, akkor azt szintén nem a proxy végzi, hanem az ezért felelős modul. Az architektúra következtében így lehetőség van bizonyos esetekben például az alapértelmezettől eltérő új kapcsolat létrehozását végző modul használatára, amely a szerverhez való sikertelen kapcsolódás esetén megpróbál egy másik szerverhez kapcsolódni. Egy moduláris tűzfal segítségével lehetőség nyílik az eddigi tűzfal által megoldhatatlan problémák biztonságosabb, flexibilisebb és gyorsabb megoldására, növelve ezzel a védendő rendszer biztonságát. A modularitás révén a tűzfal képessé válik az átmenő forgalom még részletesebb értelmezésére, ezzel segítve az adminisztrátor munkáját a IBSZ hálózati határvédelemre vonatkozó szabályainak még pontosabb betartatását illetően. Mély-protokollelemzés és content vectoring Már említettük, hogy a proxy tűzfalak alkalmazásszintű jelenlétükből kifolyólag elvileg képesek lehetnek a teljes átmenő adatforgalom elemzésére és befolyásolására. Ehhez két dolgot kell a proxy-nak teljesítenie: egyrészt ismernie kell a protokoll összes szabványos utasítását és metódusát, másrészt képesnek kell lennie a protokollban átvitt adat elemzésére. Az előbbit hívjuk mély protokollelemzésnek, míg az utóbbi a content vectoring megvalósítását jelenti. Mély-protokollelemzés Sokak számára meglepő lehet, de hiába léteznek protokollok, azok betartását alap esetben egy hálózati eszköz sem ellenőrzi. Ez nagy teret ad a rosszindulatú támadóknak, hiszen sok hálózati eszközben és alkalmazásban vannak olyan biztonsági rések, amiket, a protokollt sértő metódusokkal ki lehet játszani. 10/13

11 Amennyiben a proxy alkalmazás a teljes szabványt megvalósítja, tehát ismeri az összes utasítást és attribútumot, egyfajta hálózati rendészként minden szabványt sértő kommunikációs próbálkozást megtagadhat. További előnye a mély protokollelemzésnek, hogy segítségével a tűzfal élesebben lát. A hálózati kommunikációban jóval részletesebben tud eseményeket megkülönböztetni egymástól, aminek következtében a reakciója is kifinomultabb lehet. Content vectoring A tartalomelemzés tipikusan a moduláris tűzfalak sajátja. Önálló modulként épülnek be az architektúrába, így képesek valamennyi proxy-val együttműködni. A megoldandó feladat általában vírus szűrés a tartalomban. Ritkább esetben kulcsszavak alapján történő szűrés is előfordulhat. A Zorp technológia A Zorp tűzfal egy alkalmazás szintű, moduláris proxy tűzfal, mélyprotokollelemzési képességgel. Tehát, a legújabb technológiát képviseli. A Zorp a biztonság érdekében alkalmazás szintű proxykat és csomagszűrést egyaránt alkalmaz. Proxy-jaink fejlesztésekor cél volt az átmenő forgalom minél mélyebb elemzése és ellenőrzése, valamint a lehető legjobb konfigurálhatóság. A Zorp beépített programozási nyelvvel rendelkezik, melynek segítségével az adminisztrátor megadhatja a tűzfal beállításait, illetve testre szabhatja annak működését. A szoftver magas rendelkezésre-állást biztosító High Availability (HA) illetve titkosított virtuális magánhálózat (VPN) kialakítására alkalmas modulokkal is rendelkezik. Alkalmazás szintű átjáró A Zorp Professional a technológia jelenlegi legfejlettebb szintjét alkotó alkalmazás szintű tűzfalak családjába tartozik, így a rajta keresztülmenő forgalmat az átvitt protokollt megvalósító úgynevezett proxyk (megbízottak) ellenőrzik és továbbítják. Az alkalmazás szintű tűzfalak biztonsága azzal mérhető, hogy proxyjai milyen mélységben ellenőrzik a megvalósított protokollt. A Zorp Professional jelenleg az alábbi protokollok teljes formai elemzésére képes: FTP, HTTP, SSL, POP3, FINGER, WHOIS, NNTP, IMAP, TELNET, PRINTER, RADIUS, TFTP, LDAP, PGSQL, ORACLE NET8. Plug proxy-val bármely egy porton kommunikáló kliens szerver kapcsolat felügyelhető. (SSH, MYSQL, VNC, Microsoft Terminal Service, GOPHER, SMB/CIFS, TALK, SYSLOG, IPP, RSYNC) Modularitás és alprotokoll elemzés Az alkalmazás szintű protokollok gyakran tartalmaznak újabb alprotokollokat. Ilyen például az e-business rendszerekben érzékeny adatok átvitele esetén gyakran használt HTTPS. A HTTPS nem más, mint egy egyszerű HTTP protokoll (melyet a World Wide Web elérésére használunk) beágyazva a titkosítást végző SSL protokollba. A konkurens tűzfal termékek nem képesek az egymásba ágyazott protokollok kontrollált átvitelére, így mindössze két lehetőségünk marad: teljes mértékben tiltjuk, vagy ellenőrzés nélkül átengedjük az adott forgalmat. A Zorp szoftver modularitása lehetővé teszi, hogy ezeket az egymásba ágyazásokat is ellenőrizzük, lévén minden proxy egy olyan modul, mely képes csatlakozni bármely más modul által kiajánlott alprotokollhoz 11/13

12 Összefoglaló A fenti, igencsak rövidnek tekinthető áttekintés célja az alaptechnológiák megismertetése és a fejlődési irányvonalak felvázolása. A gyakorlatban azonban nehéz vegytiszta fogalmak alapján tájékozódni. A technológiák sokszor összemosódnak és helyes döntés meghozását tovább nehezíti, hogy egyfajta szándékos ködösítés veszi körbe marketing oldalról az egyes termékek technológiai hovatartozását. Így fordulhat elő, hogy dús fantázianevekkel megáldott grafikus interfésszel kibővített Linux csomagszűrőkbe ütközünk lépten-nyomon és idejét múlt koncepciókra támaszkodó megoldások láthatnak napfényt napjainkban is. A helyes döntés meghozásához vezető út saját igényeink alapos felmérésén keresztül található meg. Mérlegelnünk kell azt is, hogy az IT biztonságtechnikában a vírusvédelem, a behatolás védelem és a hálózati határvédelem külön fogalmakat jelentenek és általában külön eszközök segítségével valósítják meg feladataikat. Bármely informatikai rendszer biztonságát illetően rendkívül fontos a termék támogatása, supportja vagy távmenedzsmentje. A biztonság nem állapot, hanem folyamat. A legjobb megoldás sem képes hozzáértő kezelés nélkül valós biztonságot nyújtani. Lehetetlen felhívni minden buktatóra a figyelmet, hiszen nap-mint-nap találkozhatunk új fogalmakkal, mégis egy életből lopott példa kapcsán talán érzékelhetővé válik ezek jellege. Adott alkalmazás szintű termék rengeteg protokollt támogat a gyártó szerint, majd érdeklődésünkre megnyugtatnak minket, hogy egyébként is három kattintás egy új protokoll felvétele (ez úgy is elhangzott már, hogy pár kattintás segítségével kész az új proxy!). Ha azonban nem hívja fel a figyelmünket arra, hogy az így létrehozott proxy egy plug proxy és nem egy protokoll specifikus értelmező, merüljön fel bennünk a jogos gyanú, hogy a hosszú felsorolás is tartalmazhat nevesítve egyszerű plug proxy-kat. Jelentős különbség, hogy amennyiben egy gyártó nevesít egy proxy-t, mint egy adott protokoll proxy-ját a vevő feltevése szerint az egy, az adott protokollt értelmezni képes implementáció. Minél magasabb az értelmezés mélysége annál jobb biztonságtechnikai szempontból a proxy. A plug tehát a másik véglet, mivel ott alkalmazás szintű értelmezés nem történik és nem is történhet annak általános volta miatt. (A Plug proxy gyakran használt másik neve general proxy.) A gyártó részéről az elvárható etikus eljárás a plug proxy-val megvalósítható (általában véve bármely egycsatornás) protokollok és a specifikált protokollok szétválasztása. Tegyük fel tehát mindig a kérdést, amikor protokollelemzőkkel van dolgunk, hogy azok valójában milyen mélyen is értelmezik az adott protokollt. Végül pár pontba gyűjtve a legfontosabb felmerülő kérdések tűzfal technológiákat illetően: 1. A tűzfal csomagszűrő, vagy alkalmazás szintű?* 2. Amennyiben csomagszűrő technológia alapján dolgozik állapottartó-e, vagy sem? 3. Ha alkalmazás szintű, akkor mely proxy-k azok, melyek képesek a protokoll értelmezésére és melyek az úgynevezett általános, vagy plug proxy-k? 4. A protokollelemzők milyen mélyen elemzik az adott protokollt? 5. Képes-e a tűzfal biztonságosan kezelni a beágyazott protokollokat? (HTTPS) 6. A megoldás magában foglalja-e az operációs rendszer integrációját?** 7. A termék üzemeltetése során annak biztonsági frissítései magukban foglalják-e a megoldásban felhasználásra kerülő összes szoftver hibajavításait?** 8. Vannak-e valamilyen jellegű korlátozások hardver támogatásra, vagy kiépítésére vonatkozóan? 9. Mi a megoldás hardver igénye?*** 12/13

13 * Hardver alapú tűzfal sem lehet más, mint valamelyik a kettő közül. A TCP protokoll szűrésére ezen kívül nincs más módszer, általában az, hogy egy megoldás hardveres, azt jelenti, hogy valamilyen speciális konfigurációra optimalizálnak egy megoldást, ezzel növelve a teljesítményt és rendelkezésre állást. Ugyanakkor pont a kötött hardver kiépítés flexibilitási problémákhoz vezet a legtöbb esetben. Bármilyen változtatás, mely a fizikai felépítését érinti ezeknek az eszközöknek többnyire költséges és erősen limitált. (Például egy új fizikai szegmens létrehozásához szükséges hálózati csatolófelület biztosítása, vagy a teljesítmény növelésének az igénye sorolható ide.) ** Minden tűzfalmegoldás valamilyen operációs rendszeren fut. Fontos, hogy ne csak a tűzfal szoftver maga, de az őt kiszolgáló operációs rendszer és minden egyéb kiszolgáló alkalmazás napra készen frissítve legyen. Bár a legritkább eset, amikor magát a tűzfalat támadják feltehetően a védett alkalmazások kevésbe a biztonságot szem előtt tartva lettek megvalósítva, így könnyebb prédát jelentenek a fejlesztők sok esetben a tűzfal operációs rendszerét erősen átalakítják és lecsupaszítják, hogy véletlen se lehessen rajta. fogást találni. Ugyanis bármennyire nehéz feladat egy tűzfal feltörése, ha az mégis sikerülne, minden akadály elhárulna a betörő elől. *** Lényegében a hardver igény alapján a tűzfal teljesítményére lehet következtetni. A legszerencsésebb helyzet, ha találunk összehasonlító teszteket, melyek ugyanazon platformon és konfiguráción azonos körülmények között tesztelik különböző megvalósítások pl.: áteresztőképességét. Minél jobban teljesít adott szoftver annál jobban optimalizálva van a kódja, ami biztonság szempontjából sem mellékes. Sajnos ilyen tesztek nagyon nehezen találhatóak, többnyire nem publikusak és hozzá nem értő kezekben félreértésekre adhatnak okot. Nem következik a jobb kód optimalizáció abból, hogy egy csomagszűrő adott esetben gyorsabb egy alkalmazás szintű megoldásnál. Mindig mérlegelni kell azt is, hogy mennyi munkát végez egy program működése közben. (Egy applikációs szintű megvalósítás nagyságrenddel több adatot dolgoz fel, mint csomagszűrő társa.) Nyílván a kérdés másképp hangzik hardver alapú megoldásoknál. Ott a válasz abban merülhet ki, hogy adott célhardveren milyen teljesítményre képes tűzfal. Kérdéseivel, észrevételeivel keresse meg cégünket az alábbi címen: BalaBit IT Security, 1116 Budapest Csurgói út 20/B Telefon: Fax: info@balabit.hu Web: BalaBit IT Security. Minden jog fenntartva. A dokumentumra vonatkozó jogi kitételeket a következő weboldal tartalmazza: /13

Tűzfalak működése és összehasonlításuk

Tűzfalak működése és összehasonlításuk Tűzfalak működése és összehasonlításuk Készítette Sári Zoltán YF5D3E Óbudai Egyetem Neumann János Informatikai Kar 1 1. Bevezetés A tűzfalak fejlődése a számítógépes hálózatok evolúciójával párhuzamosan,

Részletesebben

Fábián Zoltán Hálózatok elmélet

Fábián Zoltán Hálózatok elmélet Fábián Zoltán Hálózatok elmélet Tűzfal fogalma Olyan alkalmazás, amellyel egy belső hálózat megvédhető a külső hálózatról (pl. Internet) érkező támadásokkal szemben Vállalati tűzfal Olyan tűzfal, amely

Részletesebben

HÁLÓZATBIZTONSÁG III. rész

HÁLÓZATBIZTONSÁG III. rész HÁLÓZATBIZTONSÁG III. rész Tűzfalak működése Összeállította: Huszár István 1. A tűzfal (firewall) szerepe Tűzfal: olyan biztonsági rendszer, amely a számítógépes hálózatok kapcsolódási pontján helyezkedik

Részletesebben

Távközlési informatika Firewall, NAT. Dr. Beinschróth József

Távközlési informatika Firewall, NAT. Dr. Beinschróth József Távközlési informatika Firewall, NAT Dr. Beinschróth József Firewall Történelem Az Internet előtti időszakban az egyes vállalatok hálózatai nem kapcsolódtak össze (kapcsolatok kivételesen léteztek pl.

Részletesebben

Tűzfal megoldások. ComNETWORX nap, 2001. I. 30. ComNETWORX Rt.

Tűzfal megoldások. ComNETWORX nap, 2001. I. 30. ComNETWORX Rt. Tűzfal megoldások ComNETORX nap, 2001. I. 30. ComNETORX Rt. N Magamról Hochenburger Róbert MCNI / MCNE MCNI = Master CNI MCNE = Master CNE CNI = Certified Novell Instructor CNE = Certified Novell Engineer

Részletesebben

A hálózati határvédelem eszközei

A hálózati határvédelem eszközei AZ INFORMATIKAI BIZTONSÁG SPECIÁLIS TÉMAKÖREI Hungarian Cyber Security Package A hálózati határvédelem eszközei Höltzl Péter A hálózati határvédelem értelmezése Tűzfal technológiák ismertetése Védelmi

Részletesebben

Számítógépes munkakörnyezet II. Szoftver

Számítógépes munkakörnyezet II. Szoftver Számítógépes munkakörnyezet II. Szoftver A hardver és a felhasználó közötti kapcsolat Szoftverek csoportosítása Számítógép működtetéséhez szükséges szoftverek Operációs rendszerek Üzemeltetési segédprogramok

Részletesebben

Bevezető. PoC kit felépítése. NX appliance. SPAN-Proxy

Bevezető. PoC kit felépítése. NX appliance. SPAN-Proxy Bevezető A dokumentum célja összefoglalni a szükséges technikai előkészületeket a FireEye PoC előtt, hogy az sikeresen végig mehessen. PoC kit felépítése A FireEye PoC kit 3 appliance-t tartalmaz: NX series:

Részletesebben

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal. Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...

Részletesebben

Szolgáltatás Orientált Architektúra a MAVIR-nál

Szolgáltatás Orientált Architektúra a MAVIR-nál Szolgáltatás Orientált Architektúra a MAVIR-nál Sajner Zsuzsanna Accenture Sztráda Gyula MAVIR ZRt. FIO 2009. szeptember 10. Tartalomjegyzék 2 Mi a Szolgáltatás Orientált Architektúra? A SOA bevezetés

Részletesebben

Technikai tudnivalók a Saxo Trader Letöltéséhez tűzfalon vagy proxy szerveren keresztül

Technikai tudnivalók a Saxo Trader Letöltéséhez tűzfalon vagy proxy szerveren keresztül Letöltési Procedúra Fontos: Ha Ön tűzfalon vagy proxy szerveren keresztül dolgozik akkor a letöltés előtt nézze meg a Technikai tudnivalók a Saxo Trader Letöltéséhez tűzfalon vagy proxy szerveren keresztül

Részletesebben

SZÁMÍTÓGÉP HÁLÓZATOK BIZTONSÁGI KÉRDÉSEI

SZÁMÍTÓGÉP HÁLÓZATOK BIZTONSÁGI KÉRDÉSEI Hálózati op. rsz 1/66 START SZÁMÍTÓGÉP HÁLÓZATOK BIZTONSÁGI KÉRDÉSEI DR. KÓNYA LÁSZLÓ http://www.aut.bmf.hu/konya konya.laszlo@kvk.bmf.hu SZERZŐI JOG DEKLARÁLÁSA: A JELEN OKTATÁSI CÉLÚ BEMUTATÓ ANYAG DR

Részletesebben

Hibrid Cloud az új Oracle Enterprise Manager Cloud Control 13c-vel

Hibrid Cloud az új Oracle Enterprise Manager Cloud Control 13c-vel Mosolygó Ferenc - Avnet Hibrid Cloud az új Oracle Enterprise Manager Cloud Control 13c-vel 1 2016 április 6. Követelmény: Üzemeltetni kell, akárhol is van az erőforrás A publikus felhőben lévő rendszereknek

Részletesebben

IPv6 Biztonság: Ipv6 tűzfalak tesztelése és vizsgálata

IPv6 Biztonság: Ipv6 tűzfalak tesztelése és vizsgálata IPv6 Biztonság: Ipv6 tűzfalak tesztelése és vizsgálata Mohácsi János Networkshop 2005 Mohácsi János, NIIF Iroda Tartalom Bevezetés IPv6 tűzfal követelmény analízis IPv6 tűzfal architektúra IPv6 tűzfalak

Részletesebben

Alapfogalmak. Biztonság. Biztonsági támadások Biztonsági célok

Alapfogalmak. Biztonság. Biztonsági támadások Biztonsági célok Alapfogalmak Biztonság Biztonsági támadások Biztonsági célok Biztonsági szolgáltatások Védelmi módszerek Hálózati fenyegetettség Biztonságos kommunikáció Kriptográfia SSL/TSL IPSec Támadási folyamatok

Részletesebben

Web service fenyegetések e- közigazgatási. IT biztonsági tanácsadó

Web service fenyegetések e- közigazgatási. IT biztonsági tanácsadó Web service fenyegetések e- közigazgatási környezetben Krasznay Csaba IT biztonsági tanácsadó HP Magyarország Kft. Bevezetése etés A Magyar Köztársaság elektronikus közigazgatási rendszere az elmúlt években

Részletesebben

Informatikai biztonság alapjai

Informatikai biztonság alapjai Informatikai biztonság alapjai 3. Rosszindulatú programok Pethő Attila 2008/9 II. félév Rosszindulatú programok (malware) fajtái vírusok, férgek, trójaiak, spyware, dishonest adware, crimeware, stb. Vírusok

Részletesebben

Internet ROUTER. Motiváció

Internet ROUTER. Motiváció Több internetvonal megosztása egy szerverrel iptables/netfilter és iproute2 segítségével Készítette: Mészáros Károly (MEKMAAT:SZE) mkaroly@citromail.hu 2007-05-22 Az ábrán látható módon a LAN-ban lévő

Részletesebben

Integrált spam, vírus, phishing és hálózati védelem az elektronikus levelezésben. Börtsök András Projekt vezető. www.nospammail.hu

Integrált spam, vírus, phishing és hálózati védelem az elektronikus levelezésben. Börtsök András Projekt vezető. www.nospammail.hu Integrált spam, vírus, phishing és hálózati védelem az elektronikus levelezésben Börtsök András Projekt vezető www.nospammail.hu Email forgalom 2010 2010. májusában Magyarország az egy főre jutó spamek

Részletesebben

Fajták és Típusok(1) Fajták és Típusok(2)

Fajták és Típusok(1) Fajták és Típusok(2) Tűzfalak Olyan szoftveres és/vagy hardveres technika, amellyel az intézmények a helyi hálózatukat megvédhetik a külsőhálózatról (jellemzően az Internetről) érkező betörések ellen, a bejövő és kimenőadatforgalom

Részletesebben

INFORMATIKA EGYRE NAGYOBB SZEREPE A KÖNYVELÉSBEN

INFORMATIKA EGYRE NAGYOBB SZEREPE A KÖNYVELÉSBEN N 1. Informatikai eszközök az irodában PC, Notebook, Szerver A számítógép típusonként az informatikai feladatoknak megfelelően. Nyomtatók, faxok, scannerek, fénymásolók Írásos dokumentum előállító eszközök.

Részletesebben

Tudjuk-e védeni dokumentumainkat az e-irodában?

Tudjuk-e védeni dokumentumainkat az e-irodában? CMC Minősítő vizsga Tudjuk-e védeni dokumentumainkat az e-irodában? 2004.02.10. Miről lesz szó? Mitvédjünk? Hogyan védjük a papírokat? Digitális dokumentumokvédelme A leggyengébb láncszem Védelem korlátai

Részletesebben

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja.

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja. A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja. A hálózat kettő vagy több egymással összekapcsolt számítógép, amelyek között adatforgalom

Részletesebben

SSL VPN KAPCSOLAT TELEPÍTÉSI ÚTMUTATÓ

SSL VPN KAPCSOLAT TELEPÍTÉSI ÚTMUTATÓ SSL VPN KAPCSOLAT TELEPÍTÉSI ÚTMUTATÓ GIRODIRECT SZOLGÁLTATÁST IGÉNYBEVEVŐ ÜGYFELEKENEK Verzió: v1.04 Dátum: 2018. január 5. Készítette: A jelen dokumentum tartalma szerzői jogi védelem alatt áll, a mű

Részletesebben

Számítógépes hálózatok

Számítógépes hálózatok 1 Számítógépes hálózatok Hálózat fogalma A hálózat a számítógépek közötti kommunikációs rendszer. Miért érdemes több számítógépet összekapcsolni? Milyen érvek szólnak a hálózat kiépítése mellett? Megoszthatók

Részletesebben

Léteznek nagyon jó integrált szoftver termékek a feladatra. Ezek többnyire drágák, és az üzemeltetésük sem túl egyszerű.

Léteznek nagyon jó integrált szoftver termékek a feladatra. Ezek többnyire drágák, és az üzemeltetésük sem túl egyszerű. 12. Felügyeleti eszközök Néhány számítógép és szerver felügyeletét viszonylag egyszerű ellátni. Ha sok munkaállomásunk (esetleg több ezer), vagy több szerverünk van, akkor a felügyeleti eszközök nélkül

Részletesebben

Grid menedzsment megoldás az ARC köztesrétegben

Grid menedzsment megoldás az ARC köztesrétegben Grid menedzsment megoldás az ARC köztesrétegben Intézetünk az Új Magyarország Fejlesztési Terv TÁMOP 4.1.3[1] alprojektjének keretén belül dolgozott ki sikeresen egy jól működő megoldást egy olyan problémára,

Részletesebben

2011.01.24. A konvergencia következményei. IKT trendek. Új generációs hálózatok. Bakonyi Péter c.docens. Konvergencia. Új generációs hálózatok( NGN )

2011.01.24. A konvergencia következményei. IKT trendek. Új generációs hálózatok. Bakonyi Péter c.docens. Konvergencia. Új generációs hálózatok( NGN ) IKT trendek Új generációs hálózatok Bakonyi Péter c.docens A konvergencia következményei Konvergencia Korábban: egy hálózat egy szolgálat Konvergencia: végberendezések konvergenciája, szolgálatok konvergenciája

Részletesebben

Silent Signal Kft. Webáruházak informatikai biztonsága Veres-Szentkirályi András 2011.03.04. 2011.03.04 Marketingtorta - 4 1

Silent Signal Kft. Webáruházak informatikai biztonsága Veres-Szentkirályi András 2011.03.04. 2011.03.04 Marketingtorta - 4 1 Silent Signal Kft. Webáruházak informatikai biztonsága Veres-Szentkirályi András 2011.03.04. 2011.03.04 Marketingtorta - 4 1 Témáink Bevezető Webáruház, mint IT rendszer biztonsága OWASP TOP10 webes hiba

Részletesebben

[SZÁMÍTÓGÉP-HÁLÓZATOK]

[SZÁMÍTÓGÉP-HÁLÓZATOK] Mérési utasítás WireShark használata, TCP kapcsolatok analizálása A Wireshark (korábbi nevén Ethereal) a legfejlettebb hálózati sniffer és analizátor program. 1998-óta fejlesztik, jelenleg a GPL 2 licensz

Részletesebben

III. előadás. Kovács Róbert

III. előadás. Kovács Róbert III. előadás Kovács Róbert VLAN Virtual Local Area Network Virtuális LAN Logikai üzenetszórási tartomány VLAN A VLAN egy logikai üzenetszórási tartomány, mely több fizikai LAN szegmensre is kiterjedhet.

Részletesebben

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba = hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba HaXSoN Szerver Vékonyterminál vékonyterminál A HaXSoN vékonyterminál jellemzői - kis méretű, alacsony fogyasztású,

Részletesebben

20. Tétel 1.0 Internet felépítése, OSI modell, TCP/IP modell szintjenek bemutatása, protokollok Pozsonyi ; Szemenyei

20. Tétel 1.0 Internet felépítése, OSI modell, TCP/IP modell szintjenek bemutatása, protokollok Pozsonyi ; Szemenyei Internet felépítése, OSI modell, TCP/IP modell szintjenek bemutatása, protokollok 28.Tétel Az Internet Felépítése: Megjegyzés [M1]: Ábra Az Internet egy világméretű számítógép-hálózat, amely kisebb hálózatok

Részletesebben

13. gyakorlat Deák Kristóf

13. gyakorlat Deák Kristóf 13. gyakorlat Deák Kristóf Tűzfal Miért kell a tűzfal? Csomagszűrés - az IP vagy MAC-cím alapján akadályozza meg vagy engedélyezi a hozzáférést. Alkalmazás/Webhely szűrés - Az alkalmazás alapján akadályozza

Részletesebben

Adatbázis kezelő szoftverek biztonsága. Vasi Sándor G-3S

Adatbázis kezelő szoftverek biztonsága. Vasi Sándor G-3S Adatbázis kezelő szoftverek biztonsága Vasi Sándor sanyi@halivud.com G-3S8 2006. Egy kis ismétlés... Adatbázis(DB): integrált adatrendszer több különböző egyed előfordulásainak adatait adatmodell szerinti

Részletesebben

1/13. RL osztály Hálózati alapismeretek I. gyakorlat c. tantárgy Osztályozóvizsga tematika

1/13. RL osztály Hálózati alapismeretek I. gyakorlat c. tantárgy Osztályozóvizsga tematika 1/13. RL osztály Hálózati alapismeretek I. gyakorlat c. tantárgy Osztályozóvizsga tematika A vizsga leírása: A vizsga anyaga a Cisco Routing and Switching Bevezetés a hálózatok világába (1)és a Cisco R&S:

Részletesebben

Alkalmazás rétegbeli protokollok:

Alkalmazás rétegbeli protokollok: Alkalmazás rétegbeli protokollok: Általában az alkalmazásban implementálják, igazodnak az alkalmazás igényeihez és logikájához, ezért többé kevésbé eltérnek egymástól. Bizonyos fokú szabványosítás viszont

Részletesebben

ÜDVÖZÖLJÜK A HaXSoN BEMUTATÓN!

ÜDVÖZÖLJÜK A HaXSoN BEMUTATÓN! ÜDVÖZÖLJÜK A HaXSoN BEMUTATÓN! info@dldh.hu www.dldh.hu Mit is jelent? Hardware-XWindow-Software-Network = hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba Kialakulás

Részletesebben

NETinv. Új generációs informatikai és kommunikációs megoldások

NETinv. Új generációs informatikai és kommunikációs megoldások Új generációs informatikai és kommunikációs megoldások NETinv távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés NETinv 1.4.2 Távközlési szolgáltatók és nagyvállatok

Részletesebben

Tarantella Secure Global Desktop Enterprise Edition

Tarantella Secure Global Desktop Enterprise Edition Tarantella Secure Global Desktop Enterprise Edition A Secure Global Desktop termékcsalád Az iparilag bizonyított szoftver termékek és szolgáltatások közé tartozó Secure Global Desktop termékcsalád biztonságos,

Részletesebben

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és

Részletesebben

ALKALMAZÁS KERETRENDSZER

ALKALMAZÁS KERETRENDSZER JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak

Részletesebben

Teljes körű weboldal, API és DDoS védelmi szolgáltatás

Teljes körű weboldal, API és DDoS védelmi szolgáltatás Közép-európai disztribútorunk a Yellow Cube. www.greywizard.com www.yellowcube.eu Teljes körű weboldal, API és DDoS védelmi szolgáltatás A Grey Wizard weboldalak, webshopok és API-k védelmét biztosító,

Részletesebben

A tűzfal mögötti adatvédelem. Kalmár István ICT technológia szakértő 2014.05.14.

A tűzfal mögötti adatvédelem. Kalmár István ICT technológia szakértő 2014.05.14. A tűzfal mögötti adatvédelem Kalmár István ICT technológia szakértő 2014.05.14. Előszó a lánc erősségét a leggyengébb láncszem határozza meg! 2014.05.14. 2 Hálózati biztonsági kérdések Tűzfal Internet

Részletesebben

Szolgáltatási szint megállapodás

Szolgáltatási szint megállapodás Szolgáltatási szint megállapodás Verzió: 1.1 (2017. november 30.) aai@niif.hu Tartalomjegyzék Tartalomjegyzésk 1 Műszaki szolgáltatások...3 1.1 Fájl-alapú metadata...3 1.1.1 Szolgáltatás URL...3 1.1.2

Részletesebben

SZÓBELI ÉRETTSÉGI TÉMAKÖRÖK

SZÓBELI ÉRETTSÉGI TÉMAKÖRÖK INFORMATIKA SZÓBELI ÉRETTSÉGI TÉMAKÖRÖK Az emelt szint a középszint követelményeit magában foglalja, de azokat magasabb szinten kéri számon. 1. Információs társadalom 2. Informatikai alapismeretek - hardver

Részletesebben

Félreértések elkerülése érdekében kérdezze meg rendszergazdáját, üzemeltetőjét!

Félreértések elkerülése érdekében kérdezze meg rendszergazdáját, üzemeltetőjét! Félreértések elkerülése érdekében kérdezze meg rendszergazdáját, üzemeltetőjét! http://m.equicomferencia.hu/ramada Liszkai János senior rendszermérnök vállalati hálózatok Miről is lesz szó? Adatközpont

Részletesebben

Autóipari beágyazott rendszerek Dr. Balogh, András

Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Publication date 2013 Szerzői jog 2013 Dr. Balogh András Szerzői jog 2013 Dunaújvárosi Főiskola Kivonat

Részletesebben

(appended picture) hát azért, mert a rendszerek sosem

(appended picture) hát azért, mert a rendszerek sosem 1 Általános kezdés: Nyilvánvaló, hogy banki, üzleti szférában fontos a biztonság, de máshol? Otthoni gépen? Személyes adatok megszerezhetőek stb. vissza lehet élni vele -> igen tényleg fontos. Beágyazott,

Részletesebben

Hálózati sávszélesség-menedzsment Linux rendszeren. Mátó Péter <atya@fsf.hu> Zámbó Marcell <lilo@andrews.hu>

Hálózati sávszélesség-menedzsment Linux rendszeren. Mátó Péter <atya@fsf.hu> Zámbó Marcell <lilo@andrews.hu> Hálózati sávszélesség-menedzsment Linux rendszeren Mátó Péter Zámbó Marcell A hálózati kapcsolatok jellemzői Tipikus hálózati kapcsolatok ISDN, analóg modem ADSL, *DSL Kábelnet,

Részletesebben

IP alapú távközlés. Virtuális magánhálózatok (VPN)

IP alapú távközlés. Virtuális magánhálózatok (VPN) IP alapú távközlés Virtuális magánhálózatok (VPN) Jellemzők Virtual Private Network VPN Publikus hálózatokon is használható Több telephelyes cégek hálózatai biztonságosan összeköthetők Olcsóbb megoldás,

Részletesebben

ERserver. iseries. Szolgáltatási minőség

ERserver. iseries. Szolgáltatási minőség ERserver iseries Szolgáltatási minőség ERserver iseries Szolgáltatási minőség Szerzői jog IBM Corporation 2002. Minden jog fenntartva Tartalom Szolgáltatási minőség (QoS)............................ 1

Részletesebben

TELE-OPERATOR UTS v.14 Field IPTV műszer. Adatlap

TELE-OPERATOR UTS v.14 Field IPTV műszer. Adatlap TELE-OPERATOR UTS v.14 Field IPTV műszer Adatlap COMPU-CONSULT Kft. 2009. augusztus 3. Dokumentáció Tárgy: TELE-OPERATOR UTS v.14 Field IPTV műszer Adatlap (6. kiadás) Kiadta: CONSULT-CONSULT Kft. Dátum:

Részletesebben

Forgalmi grafikák és statisztika MRTG-vel

Forgalmi grafikák és statisztika MRTG-vel Forgalmi grafikák és statisztika MRTG-vel Az internetes sávszélesség terheltségét ábrázoló grafikonok és statisztikák egy routerben általában opciós lehetőségek vagy még opcióként sem elérhetőek. Mégis

Részletesebben

ECDL Információ és kommunikáció

ECDL Információ és kommunikáció 1. rész: Információ 7.1 Az internet 7.1.1 Fogalmak és szakkifejezések 7.1.2 Biztonsági megfontolások 7.1.3 Első lépések a webböngésző használatában 7.1.4 A beállítások elévégzése 7.1.1.1 Az internet és

Részletesebben

Az internet az egész világot behálózó számítógép-hálózat.

Az internet az egész világot behálózó számítógép-hálózat. Az internet az egész világot behálózó számítógép-hálózat. A mai internet elődjét a 60-as években az Egyesült Államok hadseregének megbízásából fejlesztették ki, és ARPANet-nek keresztelték. Kifejlesztésének

Részletesebben

Sávszélesség szabályozás kezdőknek és haladóknak. Mátó Péter <atya@fsf.hu>

Sávszélesség szabályozás kezdőknek és haladóknak. Mátó Péter <atya@fsf.hu> Sávszélesség szabályozás kezdőknek és haladóknak Mátó Péter Az előadás témái A hálózati kapcsolatok jellemzői A hálózati protokollok jellemzői A Linux felkészítése a sávszélesség szabályzásra

Részletesebben

CCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció

CCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció CCS Hungary, 2000 szeptember Handling rendszer technikai specifikáció Hálózati architektúra SITA Hálózat/ Vám/ Internet/... CodecServer üzenet központ DB LA N Laptop computer RAS elérés Adatbázis szerver

Részletesebben

Hálózati architektúrák laborgyakorlat

Hálózati architektúrák laborgyakorlat Hálózati architektúrák laborgyakorlat 6. hét Dr. Orosz Péter, Skopkó Tamás 2012. szeptember Szállítási réteg (L4) Szolgáltatások Rétegprotokollok: TCP, UDP Port azonosítók TCP kapcsolatállapotok Alkalmazási

Részletesebben

Hálózatbiztonság 1 TCP/IP architektúra és az ISO/OSI rétegmodell ISO/OSI TCP/IP Gyakorlatias IP: Internet Protocol TCP: Transmission Control Protocol UDP: User Datagram Protocol LLC: Logical Link Control

Részletesebben

Gyakorlati vizsgatevékenység

Gyakorlati vizsgatevékenység Gyakorlati vizsgatevékenység Elágazás azonosító száma megnevezése: 4 481 03 0010 4 01 Informatikai hálózat-telepítő és -üzemeltető Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1163-06

Részletesebben

Üdvözlöm Önöket a Konferencián!

Üdvözlöm Önöket a Konferencián! Üdvözlöm Önöket a Konferencián! Nyílt Forráskódú Szoftverek a Közigazgatásban 2009. június 2., Miniszterelnöki Hivatal Foglalkoztatási és Szociális Hivatal Készítette: Kuskó István Reverse proxy megoldás

Részletesebben

Távközlési informatika II.

Távközlési informatika II. Dr. Beinschróth József Távközlési informatika II. 5.rész ÓE-KVK Budapest, 2017. Tartalom Hálózati architektúrák: szabványgyűjtemények A fizikai réteg: bitek továbbítása Az adatkapcsolati réteg: kapcsolatvezérlés

Részletesebben

A MAC-cím (Media Access Control) egy hexadecimális számsorozat, amellyel még a gyártás során látják el a hálózati kártyákat. A hálózat többi eszköze

A MAC-cím (Media Access Control) egy hexadecimális számsorozat, amellyel még a gyártás során látják el a hálózati kártyákat. A hálózat többi eszköze A MAC-cím (Media Access Control) egy hexadecimális számsorozat, amellyel még a gyártás során látják el a hálózati kártyákat. A hálózat többi eszköze a MAC-címet használja a hálózat előre meghatározott

Részletesebben

Az Internet elavult. Gyimesi István fejlesztési vezető Cardinal Számítástechnikai Kft. www.cardinal.hu

Az Internet elavult. Gyimesi István fejlesztési vezető Cardinal Számítástechnikai Kft. www.cardinal.hu Az Internet elavult Gyimesi István fejlesztési vezető Cardinal Számítástechnikai Kft wwwcardinalhu Cardinal Kft 2006 1 Elektronikus elérésre szükség van Internet híján betárcsázós ügyfélprogramok voltak:

Részletesebben

Rubin SMART COUNTER. Műszaki adatlap 1.1. Státusz: Jóváhagyva Készítette: Forrai Attila Jóváhagyta: Parádi Csaba. Rubin Informatikai Zrt.

Rubin SMART COUNTER. Műszaki adatlap 1.1. Státusz: Jóváhagyva Készítette: Forrai Attila Jóváhagyta: Parádi Csaba. Rubin Informatikai Zrt. Rubin SMART COUNTER Műszaki adatlap 1.1 Státusz: Jóváhagyva Készítette: Forrai Attila Jóváhagyta: Parádi Csaba Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax: +361

Részletesebben

30 MB INFORMATIKAI PROJEKTELLENŐR

30 MB INFORMATIKAI PROJEKTELLENŐR INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai

Részletesebben

Riverbed Sávszélesség optimalizálás

Riverbed Sávszélesség optimalizálás SCI-Network Távközlési és Hálózatintegrációs zrt. T.: 467-70-30 F.: 467-70-49 info@scinetwork.hu www.scinetwork.hu Riverbed Sávszélesség optimalizálás Bakonyi Gábor hálózati mérnök Nem tudtuk, hogy lehetetlen,

Részletesebben

Adatbázisok elleni fenyegetések rendszerezése. Fleiner Rita BMF/NIK Robothadviselés 2009

Adatbázisok elleni fenyegetések rendszerezése. Fleiner Rita BMF/NIK Robothadviselés 2009 Adatbázisok elleni fenyegetések rendszerezése Fleiner Rita BMF/NIK Robothadviselés 2009 Előadás tartalma Adatbázis biztonsággal kapcsolatos fogalmak értelmezése Rendszertani alapok Rendszerezési kategóriák

Részletesebben

VMware vsphere. Virtuális Hálózatok Biztonsága. Zrubecz.Laszlo@andrews.hu. Andrews IT Engineering Kft.

VMware vsphere. Virtuális Hálózatok Biztonsága. Zrubecz.Laszlo@andrews.hu. Andrews IT Engineering Kft. Virtuális Biztonsága Andrews IT Engineering Kft. 1 Fizikai hálózatok Virtuális hálózatok VLAN 2 Hardver környezet ESX beállítások (ESXi, ESX) 3 4 vshield Manager vshield Zones/vShield App vshield Edge

Részletesebben

Elektronikus levelek. Az informatikai biztonság alapjai II.

Elektronikus levelek. Az informatikai biztonság alapjai II. Elektronikus levelek Az informatikai biztonság alapjai II. Készítette: Póserné Oláh Valéria poserne.valeria@nik.bmf.hu Miről lesz szó? Elektronikus levelek felépítése egyszerű szövegű levél felépítése

Részletesebben

Hálózatos adatbázis-kapcsolódási problémák és azok javítása

Hálózatos adatbázis-kapcsolódási problémák és azok javítása WINTAX programrendszer hálózatos vagy helyi adatbázis-szerverhez vagy adatbázis-kezelőhöz kapcsolódáskor jelentkező kapcsolódási problémák leírása és azok megoldásai. Korábban a Hálózatos beállítás bejegyzésben

Részletesebben

Hálózati rendszerek adminisztrációja JunOS OS alapokon

Hálózati rendszerek adminisztrációja JunOS OS alapokon Hálózati rendszerek adminisztrációja JunOS OS alapokon - áttekintés és példák - Varga Pál pvarga@tmit.bme.hu Áttekintés Általános laborismeretek Junos OS bevezető Routing - alapok Tűzfalbeállítás alapok

Részletesebben

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás A Mobil multimédiás kliens fejlesztői eszközkészlet létrehozása című kutatás-fejlesztési projekthez A dokumentum célja A dokumentum

Részletesebben

MAC címek (fizikai címek)

MAC címek (fizikai címek) MAC címek (fizikai címek) Hálózati eszközök egyedi azonosítója, amit az adatkapcsolati réteg MAC alrétege használ Gyárilag adott, általában ROM-ban vagy firmware-ben tárolt érték (gyakorlatilag felülbírálható)

Részletesebben

Beállítások 1. Töltse be a Planet_NET.pkt állományt a szimulációs programba! A teszthálózat már tartalmazza a vállalat

Beállítások 1. Töltse be a Planet_NET.pkt állományt a szimulációs programba! A teszthálózat már tartalmazza a vállalat Planet-NET Egy terjeszkedés alatt álló vállalat hálózatának tervezésével bízták meg. A vállalat jelenleg három telephellyel rendelkezik. Feladata, hogy a megadott tervek alapján szimulációs programmal

Részletesebben

BEÁGYAZOTT RENDSZEREK TERVEZÉSE UDP csomag küldése és fogadása beágyazott rendszerrel példa

BEÁGYAZOTT RENDSZEREK TERVEZÉSE UDP csomag küldése és fogadása beágyazott rendszerrel példa BEÁGYAZOTT RENDSZEREK TERVEZÉSE 1 feladat: A Netburner MOD5270 fejlesztőlap segítségével megvalósítani csomagok küldését és fogadását a fejlesztőlap és egy PC számítógép között. megoldás: A fejlesztőlapra,

Részletesebben

Esettanulmány. Összetett informatikai biztonsági rendszer kiépítése pénzintézetben 1.1 verzió 2012.11.10.

Esettanulmány. Összetett informatikai biztonsági rendszer kiépítése pénzintézetben 1.1 verzió 2012.11.10. Esettanulmány Összetett informatikai biztonsági rendszer kiépítése pénzintézetben 1.1 verzió 2012.11.10. Készítette Tel.: 23/889-107 Fax: 23/889-108 E-mail: telvice@telvice.hu Web: http://www.telvice.hu/

Részletesebben

J-N-SZ MEGYEI HÁMORI ANDRÁS SZAKKÖZÉPISKOLA ÉS SZAKISKOLA

J-N-SZ MEGYEI HÁMORI ANDRÁS SZAKKÖZÉPISKOLA ÉS SZAKISKOLA Tétel sorszám: 05. Szakképesítés azonosító száma, megnevezése: 54 481 03 0000 00 00 Informatikai rendszergazda Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1163-06 Hálózat-építés, hálózati

Részletesebben

Technológia az adatszivárgás ellen

Technológia az adatszivárgás ellen 2008.12.15. Technológia az adatszivárgás ellen 2008. november 17. Fazekas Éva, Processorg Software 82 Kft. Áttekintés 1 A probléma 1. blé 2. Az elvárt eredmény 3. Megoldási lehetőségek 4. A technológia

Részletesebben

URL-LEL ADOTT OBJEKTUM LETÖLTÉSE (1) URL-LEL ADOTT OBJEKTUM LETÖLTÉSE

URL-LEL ADOTT OBJEKTUM LETÖLTÉSE (1) URL-LEL ADOTT OBJEKTUM LETÖLTÉSE Programozás III HÁLÓZATKEZELÉS A hálózatkezeléshez használatos java csomag: java. net Hol találkoztunk már vele? Pl.: URL cim = this.getclass().getresource("/zene/valami_zene.wav"); De pl. adott URL-ről

Részletesebben

A cloud szolgáltatási modell a közigazgatásban

A cloud szolgáltatási modell a közigazgatásban A cloud szolgáltatási modell a közigazgatásban Gombás László Krasznay Csaba Copyright 2011 Hewlett-Packard Development Company HP Informatikai Kft. 2011. november 23. Témafelvetés 2 HP Confidential Cloud

Részletesebben

A DNS64 és NAT64 IPv6 áttérési technikák egyes implementációinak teljesítőképesség- és stabilitás-vizsgálata. Répás Sándor

A DNS64 és NAT64 IPv6 áttérési technikák egyes implementációinak teljesítőképesség- és stabilitás-vizsgálata. Répás Sándor A DNS64 és NAT64 IPv6 áttérési technikák egyes implementációinak teljesítőképesség- és stabilitás-vizsgálata Répás Sándor Lépni Kell! Elfogytak a kiosztható IPv4-es címek. Az IPv6 1998 óta létezik. Alig

Részletesebben

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft Flash és PHP kommunikáció Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft A lehetőségek FlashVars External Interface Loadvars XML SOAP Socket AMF AMFphp PHPObject Flash Vars Flash verziótól függetlenül

Részletesebben

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása Szabó Zsolt adatbiztonság tároláskor Felhasználók hitelesítése adatbiztonság szállításkor Felhasználóknak szeparálása jogi és szabályozási kérdések incidens kezelés öntitkosító meghajtókat Hardveres Softveres

Részletesebben

Integrált-HardverSzoftver-Rendszer

Integrált-HardverSzoftver-Rendszer Integrált-HardverSzoftver-Rendszer dldh.hu dldh.hu/webshop Direct Line Kft DirectLine1 Direct-Line Kft. 2330-Dunaharaszti Jedlik Ányos u. 14. email: info@dldh.hu weblap: www.dldh.hu Történet A Direct-Line

Részletesebben

A számítástechnika gyakorlata WIN 2000 I. Szerver, ügyfél Protokoll NT domain, Peer to Peer Internet o WWW oftp opop3, SMTP. Webmail (levelező)

A számítástechnika gyakorlata WIN 2000 I. Szerver, ügyfél Protokoll NT domain, Peer to Peer Internet o WWW oftp opop3, SMTP. Webmail (levelező) A számítástechnika gyakorlata WIN 2000 I. Szerver, ügyfél Protokoll NT domain, Peer to Peer Internet o WWW oftp opop3, SMTP Bejelentkezés Explorer (böngésző) Webmail (levelező) 2003 wi-3 1 wi-3 2 Hálózatok

Részletesebben

Hálózat Használatbavételi Szabályzat (Vásárhelyi Pál Kollégium)

Hálózat Használatbavételi Szabályzat (Vásárhelyi Pál Kollégium) (Vásárhelyi Pál Kollégium) 1. Hatáskör Jelen dokumentum a Budapesti Műszaki és Gazdaságtudományi Egyetem (BME) Vásárhelyi Pál Kollégiumában lévő számítógépes hálózat használatát szabályozza. A szabályzatot

Részletesebben

8. Hálózatbiztonsági alapok. CCNA Discovery 1 8. fejezet Hálózatbiztonsági alapok

8. Hálózatbiztonsági alapok. CCNA Discovery 1 8. fejezet Hálózatbiztonsági alapok 8. Hálózatbiztonsági alapok Tartalom 8.1 A hálózati kommunikáció veszélyei 8.2 Támadási módszerek 8.3 Biztonságpolitika 8.4 Tűzfalak használata A hálózati kommunikáció veszélyei 8.1 A hálózatba való behatolás

Részletesebben

2011 TAVASZI FÉLÉV 10. LABORGYAKORLAT PRÉM DÁNIEL ÓBUDAI EGYETEM NAT/PAT. Számítógép hálózatok gyakorlata

2011 TAVASZI FÉLÉV 10. LABORGYAKORLAT PRÉM DÁNIEL ÓBUDAI EGYETEM NAT/PAT. Számítógép hálózatok gyakorlata NAT/PAT Számítógép hálózatok gyakorlata ÓBUDAI EGYETEM 2011 TAVASZI FÉLÉV 10. LABORGYAKORLAT PRÉM DÁNIEL Címkezelés problematikája Az Internetes hálózatokban ahhoz, hogy elérhetővé váljanak az egyes hálózatok

Részletesebben

Hálózatok. Alapismeretek. A hálózatok célja, építőelemei, alapfogalmak

Hálózatok. Alapismeretek. A hálózatok célja, építőelemei, alapfogalmak Hálózatok Alapismeretek A hálózatok célja, építőelemei, alapfogalmak A hálózatok célja A korai időkben terminálokat akartak használni a szabad gépidők lekötésére, erre jó lehetőség volt a megbízható és

Részletesebben

VIRTUÁLIS LAN ÉS VPN

VIRTUÁLIS LAN ÉS VPN VIRTUÁLIS LAN ÉS VPN VLAN (VIRTUAL LOCAL AREA NETWORK) A virtuális helyi hálózat lehetőséget biztosít számunkra, hogy anélkül osszuk független csoportokba a végpontokat, hogy fizikailag külön eszközökkel,

Részletesebben

PTE-PROXY VPN használata, könyvtári adatbázisok elérhetősége távolról

PTE-PROXY VPN használata, könyvtári adatbázisok elérhetősége távolról PTE-PROXY VPN használata, könyvtári adatbázisok elérhetősége távolról Az Informatikai Igazgatóság minden aktív egyetemi hallgató és munkaviszonnyal rendelkező egyetemi dolgozó részére úgynevezett proxy

Részletesebben

E mail titkosítás az üzleti életben ma már követelmény! Ön szerint ki tudja elolvasni bizalmas email leveleinket?

E mail titkosítás az üzleti életben ma már követelmény! Ön szerint ki tudja elolvasni bizalmas email leveleinket? E mail titkosítás az üzleti életben ma már követelmény! Ön szerint ki tudja elolvasni bizalmas email leveleinket? Egy email szövegében elhelyezet információ annyira biztonságos, mintha ugyanazt az információt

Részletesebben

A netfilter csomagszűrő tűzfal

A netfilter csomagszűrő tűzfal A netfilter csomagszűrő tűzfal Történelem A linux kernelben 1994 óta létezik csomagszűrési lehetőség. A nagyobb állomásokat, lépcsőket általában a usertérbeli konfigurációs program nevéhez kötik: kernel

Részletesebben

Hálózati alapismeretek

Hálózati alapismeretek Hálózati alapismeretek Tartalom Hálózat fogalma Előnyei Csoportosítási lehetőségek, topológiák Hálózati eszközök: kártya; switch; router; AP; modem Az Internet története, legfontosabb jellemzői Internet

Részletesebben

5.1 Környezet. 5.1.1 Hálózati topológia

5.1 Környezet. 5.1.1 Hálózati topológia 5. Biztonság A rendszer elsodleges célja a hallgatók vizsgáztatása, így nagy hangsúlyt kell fektetni a rendszert érinto biztonsági kérdésekre. Semmiképpen sem szabad arra számítani, hogy a muködo rendszert

Részletesebben

A Java EE 5 plattform

A Java EE 5 plattform A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11. 13. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési

Részletesebben

IBM i. Szerviz és támogatás 7.1

IBM i. Szerviz és támogatás 7.1 IBM i Szerviz és támogatás 7.1 IBM i Szerviz és támogatás 7.1 Megjegyzés A kiadvány és a tárgyalt termék használatba vétele előtt olvassa el a Nyilatkozatok, oldalszám: 111 szakasz tájékoztatását. Ez

Részletesebben

Előnyei. Helyi hálózatok tervezése és üzemeltetése 2

Előnyei. Helyi hálózatok tervezése és üzemeltetése 2 VPN Virtual Private Network A virtuális magánhálózat az Interneten keresztül kiépített titkosított csatorna. http://computer.howstuffworks.com/vpn.htm Helyi hálózatok tervezése és üzemeltetése 1 Előnyei

Részletesebben