https://miau.my-x.hu/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=Herher 2026-05-15T18:27:57Z A felhasználó közreműködései MediaWiki 1.27.7 https://miau.my-x.hu/mediawiki/index.php?title=ITT:dolgozatok&diff=36358 2009-09-14T09:17:28Z

<p>Herher: </p> <hr /> <div>Neptun/indexkód / Monogramm / Kar / Szak / Szakirány / Dolgozat címe / Státusza (TDK és/vagy szakdolgozat) / Leadás időpontja<br /> <br /> *HHJG7L/SZZS/GTK/ELM/.../Szakdolgozat/2009.09.30<br /> *WCFF2X / PGY / GTK / ISZAM / Informatika / Versengő meteorológiai előrejelzések konszolidálása / is-is / 2009.09.30.<br /> *XUMA7W / GL / GTK / ISZAM / Informatika / Online Szakértői rendszer fejlesztése / is-is / .....<br /> *JQ82K4 / PM / GTK / ISZAM / Informatika / MEZŐGAZDASÁGI SZAKTANÁCSADÁS ON-LINE TÁMOGATÁSSAL:Területválasztási szaktanácsadás tesztüzemi, illetve szimulációs adatok alapján / szakdolgozat / 2009.09.30.<br /> *H8BARD / SA / GTK / ISZAM / Informatika / MEZŐGAZDASÁGI SZAKTANÁCSADÁS ON-LINE TÁMOGATÁSSAL:On-line benchmarking tesztüzemi adatok alapján / is-is / 2009.09.30.<br /> *B8SBZ5 / KL / GTK / ISZAM / Informatika / HASONLÓSÁGELEMZÉSSEL TÁMOGATOTT ÉRTÉKBECSLÉS INGATLANIRODÁK ÉS BEFEKTETŐK SZÁMÁRA / szakdolgozat / 2009.09.30.<br /> *L7E9OH / PG / GTK / ISZAM / Informatika / Műszaki tanácsadás online támogatással: minőségtudatosság online szakértői rendszerei / szakdolgozat / 2009.09.30.<br /> *FB7TQT / KE / GTK / ISZAM / Informatika / Testre szabott Microsoft szoftver-licence meghatározása online szakértői rendszerrel / is-is / 2009.09.30<br /> *ANI2F1 / HH / GTK / ISZAM / Informatika / A Duna-Ipoly Határmenti Együttműködés - akcióterület átfogó helyzetelemzése statisztikai módszerekkel, a változások nyomon követése, a monitoring tevékenység bázisértékeinek meghatározása céljából / TDK és szakdolgozat / 2009.09.30.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=ITT:dolgozatok&diff=36353 2009-09-13T18:35:28Z

<p>Herher: </p> <hr /> <div>Neptun/indexkód / Monogramm / Kar / Szak / Szakirány / Dolgozat címe / Státusza (TDK és/vagy szakdolgozat) / Leadás időpontja<br /> <br /> *HHJG7L/SZZS/GTK/ELM/.../Szakdolgozat/2009.09.30<br /> *... / PGY / GTK / ISZAM / Informatika / Versengő meteorológiai előrejelzések konszolidálása / is-is / 2009.09.30.<br /> *XUMA7W / GL / GTK / ISZAM / Informatika / Online Szakértői rendszer fejlesztése / is-is / .....<br /> *JQ82K4 / PM / GTK / ISZAM / Informatika / MEZŐGAZDASÁGI SZAKTANÁCSADÁS ON-LINE TÁMOGATÁSSAL:Területválasztási szaktanácsadás tesztüzemi, illetve szimulációs adatok alapján / szakdolgozat / 2009.09.30.<br /> *H8BARD / SA / GTK / ISZAM / Informatika / MEZŐGAZDASÁGI SZAKTANÁCSADÁS ON-LINE TÁMOGATÁSSAL:On-line benchmarking tesztüzemi adatok alapján / szakdolgozat / 2009.09.30.<br /> *B8SBZ5 / KL / GTK / ISZAM / Informatika / HASONLÓSÁGELEMZÉSSEL TÁMOGATOTT ÉRTÉKBECSLÉS INGATLANIRODÁK ÉS BEFEKTETŐK SZÁMÁRA / szakdolgozat / 2009.09.30.<br /> *L7E9OH / PG / GTK / ISZAM / Informatika / Műszaki tanácsadás online támogatással: minőségtudatosság online szakértői rendszerei / szakdolgozat / 2009.09.30.<br /> *FB7TQT / KE / GTK / ISZAM / Informatika / Testre szabott Microsoft szoftver-licence meghatározása online szakértői rendszerrel / szakdolgozat / 2009.09.30</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=30487 2008-10-15T09:34:28Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Szakértői rendszerek szerepének feltárása a Windowsról Linuxra történő áttérés vizsgálata során felismert tudáselemek rendszerezésében<br /> =A feladat előtörténete, motivációk=<br /> Évek óta sok ember érintett a számítástechnikában és az internetben, nagy reményeket fektettek abba, hogy a Linux esetleg életképes operációs rendszerré válik az általános célú felhasználok szélesebb körében. Azonban a problémákkal a csalódottság is megnövekedett és a kereskedelemben csak egy uralkodó felület van jelen amelyet a Microsoft forgalmaz. Viszont ez a csalódottság arra ösztönzi a piacot, hogy növelje az alternatív felületek választékát .<br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> =A feladat által érintett célcsoportok=<br /> Olyan embereknek nyújt majd segítséget, akik szeretnének Windows operációs rendszerről valamilyen más, nyílt forráskódú szofetverre váltani. <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> Mikor érdemes illetve egyáltalán megéri-e a nyílt forráskódú szoftverek használatára áttérni.<br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Egy fiktív polgármesteri hivatalban szeretném vizsgálni, annak lehetőségét, hogy megvalósítható-e, illetve gazdaságos-e a különböző kereskedelmi szoftverek nyílt forráskódú szoftverekkel történő kiváltása, illetve ezek használati arányának növelése. A vizsgálat elsődlegesen gazdasági oldalról történik, amelynek lényege, hogy megérné-e az önkormányzatnak a nyílt forráskódú szoftverekre való áttérés, figyelembe véve az átállás időtartamát, átképzési költségeket, illetve az új szoftverkörnyezet bevezetéséből fakadó esetleges munkaidő-kiesést. A pénzügyi szempontok mellett külön vizsgálom a megvalósíthatóságot.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=30486 2008-10-15T09:33:24Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Szakértői rendszerek szerepének feltárása a Windowsról Linuxra történő áttérés vizsgálata során felismert tudáselemek rendszerezésében<br /> =A feladat előtörténete, motivációk=<br /> Évek óta sok ember érintett a számítástechnikában és az internetben, nagy reményeket fektettek abba, hogy a Linux esetleg életképes operációs rendszerré válik az általános célú felhasználok szélesebb körében. Azonban a problémákkal a csalódottság is megnövekedett és a kereskedelemben csak egy uralkodó felület van jelen amelyet a Microsoft forgalmaz. Viszont ez a csalódottság arra ösztönzi a piacot, hogy növelje az alternatív felületek választékát .<br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> =A feladat által érintett célcsoportok=<br /> Olyan embereknek nyújt majd segítséget, akik szeretnének Windows operációs rendszerről valamilyen más, nyílt forráskódú szofetverre váltani. <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> Segítséget nyújt abban, hogy mikor érdemes illetve egyáltalán megéri-e a nyílt forráskódú szoftverek használatára áttérni.<br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Egy fiktív polgármesteri hivatalban szeretném vizsgálni, annak lehetőségét, hogy megvalósítható-e, illetve gazdaságos-e a különböző kereskedelmi szoftverek nyílt forráskódú szoftverekkel történő kiváltása, illetve ezek használati arányának növelése. A vizsgálat elsődlegesen gazdasági oldalról történik, amelynek lényege, hogy megérné-e az önkormányzatnak a nyílt forráskódú szoftverekre való áttérés, figyelembe véve az átállás időtartamát, átképzési költségeket, illetve az új szoftverkörnyezet bevezetéséből fakadó esetleges munkaidő-kiesést. A pénzügyi szempontok mellett külön vizsgálom a megvalósíthatóságot.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=30177 2008-10-11T13:58:12Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Szakértői rendszerek szerepének feltárása a Windowsról Linuxra történő áttérés vizsgálata során felismert tudáselemek rendszerezésében<br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> <br /> =A feladat által érintett célcsoportok=<br /> <br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=29967 2008-10-08T13:00:54Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása (szakértői rendszerrel)<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> A jelenlegi helyzetben adottak a különböző emulátorok, amelyek képesek Windows környezetet szimulálni a különböző programok számára.<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Tesztelésre kerülnek a Windowsra megírt és a Windows operációs rendszerre optimalizált programok futtatásának,alkalmazásának lehetősége Linux op. rendszer alatt, emulátorok segítségével,melynek során vizsgálom az emulátorok és a programok kompatibilitását,stabilitását, valamint használhatóságát felhasználói szemmel.A vizsgálat Ubuntu 8.04 LTS op.rendszer alatt többek között Wine windows emulátor segítségével történik.A közintézményekben használt programok kerülnek tesztelésre pl.Polgármesteri hivatalban használt programok.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=28908 2008-09-22T17:26:45Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása (szakértői rendszer)<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> A jelenlegi helyzetben adottak a különböző emulátorok, amelyek képesek Windows környezetet szimulálni a különböző programok számára.<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Tesztelésre kerülnek a Windowsra megírt és a Windows operációs rendszerre optimalizált programok futtatásának,alkalmazásának lehetősége Linux op. rendszer alatt, emulátorok segítségével,melynek során vizsgálom az emulátorok és a programok kompatibilitását,stabilitását, valamint használhatóságát felhasználói szemmel.A vizsgálat Ubuntu 8.04 LTS op.rendszer alatt többek között Wine windows emulátor segítségével történik.A közintézményekben használt programok kerülnek tesztelésre pl.Polgármesteri hivatalban használt programok.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=28907 2008-09-22T17:25:07Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása (szakértői rendszer)<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> A jelenlegi helyzetben adottak a különböző emulátorok, amelyek képesek Windows környezetet szimulálni a különböző programok számára,de nincs olyan szakértői rendszer, amely segítséget nyújtana egy migrációs probléma esetén.(Windoswsról Linuxra)<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> A feladat megoldásának eredménye, egy olyan szakértői rendszer, amely Windowsra írt, de Linux alatt használatos program alatt fellépő problémák orvosolásához nyújt segítséget.<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Tesztelésre kerülnek a Windowsra megírt és a Windows operációs rendszerre optimalizált programok futtatásának,alkalmazásának lehetősége Linux op. rendszer alatt, emulátorok segítségével,melynek során vizsgálom az emulátorok és a programok kompatibilitását,stabilitását, valamint használhatóságát felhasználói szemmel.A vizsgálat Ubuntu 8.04 LTS op.rendszer alatt többek között Wine windows emulátor segítségével történik.A közintézményekben használt programok kerülnek tesztelésre pl.Polgármesteri hivatalban használt programok.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=27524 2008-05-13T12:14:16Z

<p>Herher: /* A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice) */</p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása szakértői rendszerrel.<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> A jelenlegi helyzetben adottak a különböző emulátorok, amelyek képesek Windows környezetet szimulálni a különböző programok számára,de nincs olyan szakértői rendszer, amely segítséget nyújtana egy migrációs probléma esetén.(Windoswsról Linuxra)<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> A feladat megoldásának eredménye, egy olyan szakértői rendszer, amely Windowsra írt, de Linux alatt használatos program alatt fellépő problémák orvosolásához nyújt segítséget.<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Tesztelésre kerülnek a Windowsra megírt és a Windows operációs rendszerre optimalizált programok futtatásának,alkalmazásának lehetősége Linux op. rendszer alatt, emulátorok segítségével,melynek során vizsgálom az emulátorok és a programok kompatibilitását,stabilitását, valamint használhatóságát felhasználói szemmel.A vizsgálat Ubuntu 8.04 LTS op.rendszer alatt többek között Wine windows emulátor segítségével történik.A közintézményekben használt programok kerülnek tesztelésre pl.Polgármesteri hivatalban használt programok.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=27523 2008-05-13T12:11:51Z

<p>Herher: /* A feladat megválaszolása kapcsán várható hasznosság */</p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása szakértői rendszerrel.<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> A feladat megoldásának eredménye, egy olyan szakértői rendszer, amely Windowsra írt, de Linux alatt használatos program alatt fellépő problémák orvosolásához nyújt segítséget.<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Tesztelésre kerülnek a Windowsra megírt és a Windows operációs rendszerre optimalizált programok futtatásának,alkalmazásának lehetősége Linux op. rendszer alatt, emulátorok segítségével,melynek során vizsgálom az emulátorok és a programok kompatibilitását,stabilitását, valamint használhatóságát felhasználói szemmel.A vizsgálat Ubuntu 8.04 LTS op.rendszer alatt többek között Wine windows emulátor segítségével történik.A közintézményekben használt programok kerülnek tesztelésre pl.Polgármesteri hivatalban használt programok.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=27522 2008-05-13T12:07:41Z

<p>Herher: /* A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t */</p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása szakértői rendszerrel.<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=<br /> Tesztelésre kerülnek a Windowsra megírt és a Windows operációs rendszerre optimalizált programok futtatásának,alkalmazásának lehetősége Linux op. rendszer alatt, emulátorok segítségével,melynek során vizsgálom az emulátorok és a programok kompatibilitását,stabilitását, valamint használhatóságát felhasználói szemmel.A vizsgálat Ubuntu 8.04 LTS op.rendszer alatt többek között Wine windows emulátor segítségével történik.A közintézményekben használt programok kerülnek tesztelésre pl.Polgármesteri hivatalban használt programok.</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=27521 2008-05-12T19:52:54Z

<p>Herher: /* A feladat által érintett célcsoportok */</p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása szakértői rendszerrel.<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> <br /> =A feladat által érintett célcsoportok=<br /> A rendszergazdák illetve a komolyabb felhasználók.<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=27520 2008-05-12T19:50:54Z

<p>Herher: </p> <hr /> <div>=A szakdolgozat címe=<br /> Windowsról Linuxra történő áttérés esetén jelentkező migrációs problémák megoldása szakértői rendszerrel.<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> <br /> =A feladat által érintett célcsoportok=<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C3%A9ma:Kurucz_Eszter&diff=27519 2008-05-12T19:49:47Z

<p>Herher: New page: =A szakdolgozat címe= =A feladat előtörténete, motivációk= =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)= =A feladat által érintett célcs...</p> <hr /> <div>=A szakdolgozat címe=<br /> <br /> =A feladat előtörténete, motivációk=<br /> <br /> =A feladat megoldásának jelenlegi helyzete és ennek értékelése (best practice)=<br /> <br /> =A feladat által érintett célcsoportok=<br /> <br /> =A feladat megválaszolása kapcsán várható hasznosság=<br /> <br /> =A tervezett megoldás bemutatása, avagy miben tervezi meghaladni a hallgató a best practice-t=</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=DM-blokk&diff=23296 2007-10-26T09:20:15Z

<p>Herher: /* Kurucz Eszter */</p> <hr /> <div>=2007.10.26. - Adatbányászati blokk=<br /> ==Brechler Zsolt==<br /> Döntési fákkal fogunk foglalkozni.<br /> Weka tudományos szempontból érdekes,többet tud mint egy SPSS.<br /> *Adatbányászat/tudáskinyerés: implicit módon tudnak előállni.<br /> ADöntési fákkal fogunk foglalkozni.<br /> *tranzakciós adatbázisrendszer,vezetői információs rendszer,adattárház,adatpiac<br /> <br /> ==Tuzes Gyorgy==<br /> <br /> adatbanyaszati modelleket leginkabb banki kornyezetekbe hasznaljak<br /> <br /> fobb hasznalati teruletek<br /> <br /> -lemorzsolodas vizsgalat<br /> -ugyfelszegmentacio<br /> -kockazatelemzes<br /> <br /> Alkalmazza a mesterseges intellignciat.<br /> <br /> ==Kurucz Eszter==<br /> '''Adatbányászat feladata:'''<br /> *Leíró adatbányászat:egy adathalmaz tulajdonságainak tömör feltárása.<br /> *prediktív adatbányászat:Jövőben viselkedés előrejelzése.<br /> A prediktív adatbányászathoz tartozik az osztályozás, melynek módszerei közé tartozik :<br /> *Döntési fák<br /> *Logisztikus regresszió<br /> *Mesterséges neurális hálózatok<br /> <br /> '''Döntési fák:'''<br /> *Egyszerű,könnyen értelmezhető módon ábrázolják azt a szabályrendszert, mellyel az objektumokat rendezzük.<br /> *Ha..,akkor... típusú szabályokkal is megfogalmazhatjuk.<br /> *A fa építésnél meg kell határozni, hogy melyik résznél történjen a vágás.<br /> Entropia:alkalmas a rendezettség mérésére.<br /> <br /> '''Mesterséges neurális hálózatok:'''<br /> *kategóri és folytonos függő változót is képesek kezelni<br /> *felépítése:<br /> **Bemeneti réteg<br /> **Rejtett réteg<br /> **Kimeneti réteg<br /> <br /> ==Bicók Csongor==<br /> ==Horváth Henrietta==<br /> ==Gáncs Júlia==<br /> ==Bogyay Gábor==<br /> ==Vékony Viola==<br /> <br /> Adatbányászat feladata:<br /> *Leíró adatbányászat<br /> *prediktív adatbányászat<br /> <br /> ==Pauleczki Mihály==<br /> ==Sápi András==<br /> Döntéshozó,weka,spss.Az adatbányászat tudáskinyerés.Forrás rendszerek v. tranzakciós rendszrek.Adattárház:elemzői szempontból releváns adatokat tartalmaz,innen nyerjük ki a rengeteg adatból ami majd kell az adatpiacnak.<br /> ==Putnoki Gyula==<br /> <br /> =2007.11.09. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==<br /> <br /> <br /> =2007.11.30. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=DM-blokk&diff=23295 2007-10-26T09:19:28Z

<p>Herher: /* Kurucz Eszter */</p> <hr /> <div>=2007.10.26. - Adatbányászati blokk=<br /> ==Brechler Zsolt==<br /> Döntési fákkal fogunk foglalkozni.<br /> Weka tudományos szempontból érdekes,többet tud mint egy SPSS.<br /> *Adatbányászat/tudáskinyerés: implicit módon tudnak előállni.<br /> ADöntési fákkal fogunk foglalkozni.<br /> *tranzakciós adatbázisrendszer,vezetői információs rendszer,adattárház,adatpiac<br /> <br /> ==Tuzes Gyorgy==<br /> <br /> adatbanyaszati modelleket leginkabb banki kornyezetekbe hasznaljak<br /> <br /> fobb hasznalati teruletek<br /> <br /> -lemorzsolodas vizsgalat<br /> -ugyfelszegmentacio<br /> -kockazatelemzes<br /> <br /> Alkalmazza a mesterseges intellignciat.<br /> <br /> ==Kurucz Eszter==<br /> Adatbányászat feladata:<br /> *Leíró adatbányászat:egy adathalmaz tulajdonságainak tömör feltárása.<br /> *prediktív adatbányászat:Jövőben viselkedés előrejelzése.<br /> A prediktív adatbányászathoz tartozik az osztályozás, melynek módszerei közé tartozik :<br /> *Döntési fák<br /> *Logisztikus regresszió<br /> *Mesterséges neurális hálózatok<br /> <br /> '''Döntési fák:'''<br /> *Egyszerű,könnyen értelmezhető módon ábrázolják azt a szabályrendszert, mellyel az objektumokat rendezzük.<br /> *Ha..,akkor... típusú szabályokkal is megfogalmazhatjuk.<br /> *A fa építésnél meg kell határozni, hogy melyik résznél történjen a vágás.<br /> Entropia:alkalmas a rendezettség mérésére.<br /> <br /> '''Mesterséges neurális hálózatok:'''<br /> *kategóri és folytonos függő változót is képesek kezelni<br /> *felépítése:<br /> **Bemeneti réteg<br /> **Rejtett réteg<br /> **Kimeneti réteg<br /> <br /> ==Bicók Csongor==<br /> ==Horváth Henrietta==<br /> ==Gáncs Júlia==<br /> ==Bogyay Gábor==<br /> ==Vékony Viola==<br /> <br /> Adatbányászat feladata:<br /> *Leíró adatbányászat<br /> *prediktív adatbányászat<br /> <br /> ==Pauleczki Mihály==<br /> ==Sápi András==<br /> Döntéshozó,weka,spss.Az adatbányászat tudáskinyerés.Forrás rendszerek v. tranzakciós rendszrek.Adattárház:elemzői szempontból releváns adatokat tartalmaz,innen nyerjük ki a rengeteg adatból ami majd kell az adatpiacnak.<br /> ==Putnoki Gyula==<br /> <br /> =2007.11.09. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==<br /> <br /> <br /> =2007.11.30. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=DM-blokk&diff=23294 2007-10-26T09:04:57Z

<p>Herher: /* Kurucz Eszter */</p> <hr /> <div>=2007.10.26. - Adatbányászati blokk=<br /> ==Brechler Zsolt==<br /> Döntési fákkal fogunk foglalkozni.<br /> Weka tudományos szempontból érdekes,többet tud mint egy SPSS.<br /> *Adatbányászat/tudáskinyerés: implicit módon tudnak előállni.<br /> ADöntési fákkal fogunk foglalkozni.<br /> *tranzakciós adatbázisrendszer,vezetői információs rendszer,adattárház,adatpiac<br /> <br /> ==Tuzes Gyorgy==<br /> <br /> adatbanyaszati modelleket leginkabb banki kornyezetekbe hasznaljak<br /> <br /> fobb hasznalati teruletek<br /> <br /> -lemorzsolodas vizsgalat<br /> -ugyfelszegmentacio<br /> -kockazatelemzes<br /> <br /> Alkalmazza a mesterseges intellignciat.<br /> <br /> ==Kurucz Eszter==<br /> Adatbányászat feladata:<br /> *Leíró adatbányászat:egy adathalmaz tulajdonságainak tömör feltárása.<br /> *prediktív adatbányászat:Jövőben viselkedés előrejelzése.<br /> A prediktív adatbányászathoz tartozik az osztályozás, melynek módszerei közé tartozik :<br /> *Döntési fák<br /> *Logisztikus regresszió<br /> *Mesterséges neurális hálózatok<br /> <br /> '''Döntési fák:'''<br /> *Egyszerű,könnyen értelmezhető módon ábrázolják azt a szabályrendszert, mellyel az objektumokat rendezzük.<br /> *Ha..,akkor... típusú szabályokkal is megfogalmazhatjuk.<br /> *A fa építésnél meg kell határozni, hogy melyik résznél történjen a vágás.<br /> <br /> ==Bicók Csongor==<br /> ==Horváth Henrietta==<br /> ==Gáncs Júlia==<br /> ==Bogyay Gábor==<br /> ==Vékony Viola==<br /> <br /> Adatbányászat feladata:<br /> *Leíró adatbányászat<br /> *prediktív adatbányászat<br /> <br /> ==Pauleczki Mihály==<br /> ==Sápi András==<br /> Döntéshozó,weka,spss.Az adatbányászat tudáskinyerés.Forrás rendszerek v. tranzakciós rendszrek.Adattárház:elemzői szempontból releváns adatokat tartalmaz,innen nyerjük ki a rengeteg adatból ami majd kell az adatpiacnak.<br /> ==Putnoki Gyula==<br /> <br /> =2007.11.09. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==<br /> <br /> <br /> =2007.11.30. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=DM-blokk&diff=23291 2007-10-26T08:50:39Z

<p>Herher: /* Kurucz Eszter */</p> <hr /> <div>=2007.10.26. - Adatbányászati blokk=<br /> ==Brechler Zsolt==<br /> Döntési fákkal fogunk foglalkozni.<br /> Weka tudományos szempontból érdekes,többet tud mint egy SPSS.<br /> *Adatbányászat/tudáskinyerés: implicit módon tudnak előállni.<br /> ADöntési fákkal fogunk foglalkozni.<br /> *tranzakciós adatbázisrendszer,vezetői információs rendszer,adattárház,adatpiac<br /> <br /> ==Tuzes Gyorgy==<br /> <br /> adatbanyaszati modelleket leginkabb banki kornyezetekbe hasznaljak<br /> <br /> fobb hasznalati teruletek<br /> <br /> -lemorzsolodas vizsgalat<br /> -ugyfelszegmentacio<br /> -kockazatelemzes<br /> <br /> Alkalmazza a mesterseges intellignciat.<br /> <br /> ==Kurucz Eszter==<br /> Adatbányászat feladata:<br /> *Leíró adatbányászat:egy adathalmaz tulajdonságainak tömör feltárása.<br /> *prediktív adatbányászat:Jövőben viselkedés előrejelzése.<br /> <br /> ==Bicók Csongor==<br /> ==Horváth Henrietta==<br /> ==Bogyay Gábor==<br /> ==Vékony Viola==<br /> ==Pauleczki Mihály==<br /> ==Sápi András==<br /> Döntéshozó,weka,spss.Az adatbányászat tudáskinyerés.Forrás rendszerek v. tranzakciós rendszrek.Adattárház:elemzői szempontból releváns adatokat tartalmaz,innen nyerjük ki a rengeteg adatból ami majd kell az adatpiacnak.<br /> ==Putnoki Gyula==<br /> <br /> =2007.11.09. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==<br /> <br /> <br /> =2007.11.30. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=DM-blokk&diff=23290 2007-10-26T08:42:36Z

<p>Herher: /* Kurucz Eszter */</p> <hr /> <div>=2007.10.26. - Adatbányászati blokk=<br /> ==Brechler Zsolt==<br /> Döntési fákkal fogunk foglalkozni.<br /> Weka tudományos szempontból érdekes,többet tud mint egy SPSS.<br /> *Adatbányászat/tudáskinyerés: implicit módon tudnak előállni.<br /> ADöntési fákkal fogunk foglalkozni.<br /> *tranzakciós adatbázisrendszer,vezetői információs rendszer,adattárház,adatpiac<br /> <br /> ==Tuzes Gyorgy==<br /> <br /> adatbanyaszati modelleket leginkabb banki kornyezetekbe hasznaljak<br /> <br /> fobb hasznalati teruletek<br /> <br /> -lemorzsolodas vizsgalat<br /> -ugyfelszegmentacio<br /> -kockazatelemzes<br /> <br /> Alkalmazza a mesterseges intellignciat.<br /> <br /> ==Kurucz Eszter==<br /> <br /> ==Bicók Csongor==<br /> ==Horváth Henrietta==<br /> ==Bogyay Gábor==<br /> ==Vékony Viola==<br /> ==Pauleczki Mihály==<br /> ==Sápi András==<br /> Döntéshozó,weka,spss.Az adatbányászat tudáskinyerés.Forrás rendszerek v. tranzakciós rendszrek.Adattárház:elemzői szempontból releváns adatokat tartalmaz,innen nyerjük ki a rengeteg adatból ami majd kell az adatpiacnak.<br /> ==Putnoki Gyula==<br /> <br /> =2007.11.09. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==<br /> <br /> <br /> =2007.11.30. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=DM-blokk&diff=23277 2007-10-26T08:08:06Z

<p>Herher: /* zq */</p> <hr /> <div>=2007.10.26. - Adatbányászati blokk=<br /> ==Brechler Zsolt==<br /> ==Kurucz Eszter==<br /> <br /> ==Bogyay Gábor==<br /> =2007.11.09. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==<br /> <br /> <br /> =2007.11.30. - Adatbányászati blokk=<br /> ==xy==<br /> ==zq==</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C5%B1zfalak&diff=17174 2006-12-14T12:51:49Z

<p>Herher: /* Történeti Modul */</p> <hr /> <div>=Történeti Modul=<br /> *'''1980:'''A tűzfal az 1980as évek környékén bukkant fel amikor az Internet egy egészen új technologiaként jelent meg. <br /> *'''1988:''' ''Első generáció a csomagszűrő(Packet filter):''Az első publikált tűzfalas technológia ebben az évben jött létre, amikor Digital Equipment Corporation (DEC)-től ismertetett egy fejlett szűrő rendszert, csomagszűrő tűzfalként. Ez a felbukkant rendszer volt az első generáció. <br /> *'''1980-1990:''' ''Második generáció(Circuit level):''1980 és 1990 között az AT&amp;T Bell Laboratórium két munkatársa, Dave Presetto és Howard Trickey, feltalálta a második generációs tűzfalat amely '''circuit level''' tűzfal néven vált ismertté.<br /> *''Harmadik Generáció (Application Layer) Alkalmazás szintű tűzfal:''Gene Spafford a Purdue Egyetemről, Bill Cheswick az AT&amp;T Laboratóriumból és Marcus Ranum által kitalált harmadik generációs tűzfal: application layer tűzfal vagy másnéven proxy tűzfal.<br /> *'''1992:''' ''Újabb generációk:''Bob Braden és Anette DeSchin a Kelet Kaliforniai Egyetemen(USC) kitalálták a negyedik geneációs csomag szűrő rendszert. A termék mint &quot;Visas&quot; volt az első rendszer amely rendelkezett vizuális felülettel, szinekkel és ikonokkal, amelyek végrehajtották és elfogadták a [[Microsoft Windows]] vagy az [[Apple MacOs]]-t mint operációs rendszert. 1994-ben egy Izraeli cég amelyet [[Check Point Software Technologies]]-nek hívtak, készítette el a [[FireWall-1]] szoftvert.<br /> *'''Proxy:'''A második generációja a proxy tűzfalaknak volt a Kernel Proxy technológia. Ez a tervezés folyamatosan fejlődik, de ez alapvetőleg tagolt és kódolt, jelenleg széleskörűen használják mind a kereskedelemben mind pedig a hazai számítógépes rendszerekben. A Cisco az egyik legnagyobb és legismertebb internetes védelmi cég a világon különösen ennek a cégnek a PIX termékük amelyet 1997-ben publikáltak.<br /> Az új következő generációs tűzfalak hatalma a fennálló alapos csomag vizsgálat az IPS által.<br /> <br /> =Definíciós Modul=<br /> <br /> *'''Csomagszűrés:'''<br /> Ha jobban belegondolunk, két helyen nyílik lehetőség a „teljes” forgalom ellenőrzésére, a felhasználó számítógépén – erre jöttek létre a személyi tűzfalak – vagy a routereknél (útválasztó). Mint a nevéből is kitűnik, a router felelős azért hogy egy csomag a megfelelő célba jusson. Legalábbis kezdetben ez volt a dolguk, de így egy új feladatot is kaptak, méghozzá a csomagok szűrését, kontrollálását és a kapcsolatok felügyeletét, hiszen ez az a „pont” amin a teljes hálózati forgalom keresztülhalad. Ezen csomagszűrési feladat elvégzésére Linux alatt az iptables nevű program nyújtja a talán legérthetőbb és legkönnyebben alkalmazható megoldást. A csomagszűrők három legfontosabb lánccal dolgoznak – ennél azért több van – ezek az input, output, valamint a forward lánc. Az input lánchoz a routerbe beérkező csomagok mennek, az outputhoz a routerből kifelé haladó, a forward lánchoz pedig a két hálózati kártya között haladó csomagok. Minden lánchoz tartoznak szabályok, amelyeket mi adunk meg valamint egy döntés, ami a csomag szabályra való illeszkedése esetén következik be, ezt szintén mi definiálhatjuk.Többféle szűrést is végezhetünk, a legtriviálisabb az [[IP]](ez [[DHCP]] esetében problémás) illetve [[MAC]] címre való szűrés valamint a „kiegészítő információkat”([[TCP]] flageket) is figyelembe tudjuk venni pl [[SYN]], [[ACK]] stb… Lehetőségünk nyílik magasabb rétegbeli(pl. adatkapcsolati réteg) információk alapján is döntést hozni, pl. port alapú szűrést végezni. A legtöbb csomagszűrő lehetőséget kínál – így az iptables is – a [[NAT]](Network Address Translation) elvégzésére ([[PREROUTING]], [[POSTROUTING]] lánc segítségével) valamint naplózásra is. Az előbb említett [[NAT]], tulajdonképpen a hálózati címfordítás pl. adott esetben egy cég egyetlen publikus ip címmel rendelkezik az internet felé, de a hálózat több gépe is kapcsolódik az internetre mégpedig a routeren keresztül, ami elvégzi a címfordítást, azaz kifelé minden gép egy ip cím alól „látszik”. Az egyik hátránya az, hogy nem kínál tökéletes védelmet, mivel csak a csomagok fejlécét vizsgálja és a csomagokat is „egyenként”, nincs lehetőség a [[TCP]] kapcsolat teljes felügyeletére. Az állapottartás hiánya miatt pedig problémás a több porton folyó kommunikáció kezelése mint pl. az [[FTP]] esetében.<br /> <br /> **'''Állapottartó csomagszűrők:'''<br /> A csomagszűrők egyik továbbfejlesztett változata az állapottartó csomagszűrők családja. Az alkalmazások fejlődése megkövetelte, hogy az ismeretlen serverekkel történő kommunikációt is biztonságosabbá lehessen tenni. Erre az elektronikus kereskedelem megjelenésével kimondottan nagy szükség volt. Az állapottartó csomagszűrők egy bizonyos ideig tárolják a beérkező csomagokat, és csak a megfelelő információ birtokában döntenek, úgy, hogy a csomagok közötti összefüggéseket is figyelembe veszik. A tűzfalnak azonosítania kell a kapcsolat kezdetét és végét és ezáltal az ezek között zajló folyamatot. Ezek alapján a kapcsolatba nem illő csomagokat tudja azonosítani. Tehát az állapottartó csomagszűrés az egész kapcsolatot képes vizsgálni, míg az előző csomagszűrési fajta „csak” magát a csomagot vizsgálta. Pédául egy TCP kapcsolat esetén nem csak az [[ACK]] flag megléte, esetleg hiánya, hanem az egész kapcsolat nyomon követése adja meg az információt a döntéshez. A vizsgálatok mélysége között alapvetőleg nincs különbség, hanem csak a kapott információ feldolgozásában. Az állapottartó csomagszűrő meg tudja különböztetni pl. a kapcsolat kiépítését kezdeményező csomagokat valamint annak lezárását kezdeményező csomagokat és már „gyanús lehet számára” ha pl. egy adat csomag megelőzi a kapcsolat kiépülését kezdeményező csomagot. Tehát ez a csomagszűrés az egész kapcsolatot képes felügyelni. Egyébként ezek a csomagszűrők is szabályláncokkal dolgoznak, elődjükhöz hasonlóan. Persze ez a megoldás sem nyújt tökéletes védelmet, gondoljunk csak arra, hogy a csomagszűréssel csak az adott csomag mintegy 5% -át – a csomag fejlécét – vizsgáljuk és a „maradék” 95% mehet tovább, adatként, ami ugye bármit tartalmazhat. A megoldást az alkalmazásszintű tűzfalak vagy proxyk megjelenése jelentette, amelyek a csomagszűrőkkel kb. egyszerre kezdtek fejlődni(párhuzamosan).<br /> <br /> *'''Bastion Host avagy bástya hoszt:'''<br /> A tűzfalak egy következő alternatívája a Bastion Host volt, ami igazából nem teljesen nevezhető tűzfalnak, mert ez tulajdonképpen egy server gép, amire a felhasználók be tudnak jelentkezni és az erőforrásait igénybe tudják venni, egyszerre akár több felhasználó is(multiuseres üzemmód). Tulajdonképpen két kapcsolat van, az egyik a felhasználó és a Bastion Host, a másik pedig a Bastion Host és az internetes server között. Ha a felhasználó valamit el akart érni a neten, akkor előbb be kellett jelentkeznie a Bastion Hostra és azon kezdeményezheti az erőforrás elérését. A felhasználó gépe és a server között nincs direkt csomagkapcsolat. Ez jóval megnehezíti, vagy lehetetlenné teszi a csomagszintű támadásokat. Ettől kezdve már nem a csomagra fogunk koncentrálni, hanem a kapcsolatra, a kapcsolatorientált protokollok miatt is. A tűzfalak képesek lesznek betekinteni a csomagok adat részébe is. A Bastion Host nevű megoldás egy továbbfejlesztett változata a [[Proxy]] illetve a Socks tűzfalak.<br /> <br /> *'''A Socks tűzfalak:'''<br /> A Socks tűzfalak valahol „középen” helyezkednek el a [[Proxy]] és a csomagszűrők között. Csomagszűrőnek nem nevezhetőek, mert a kliens és a server között nem mennek csomagok de alkalmazásszintűnek sem nevezhető mert a hálózati szintre tehető a működése. Ezen megoldások igen rövid életűek voltak. A Socks Proxy lényege az, hogy a felhsználó gépére telepítésre kerül egy program, ami átveszi a hálózati kapcsolatok kezelését az operációs rendszertől. Ha a felhasználó kapcsolódni szeretne egy serverhez, akkor ezt a telepített program intézi, oly módon, hogy kapcsolódik a [[Socks Proxy]] egy adott portjához, és „megmondja” neki, hogy mihez szeretne kapcsolódni. Majd a[[ Proxy]] fog kapcsolódni a kliens által megadott serverhez. A kliens az adatforgalmát a Socks Proxyn keresztül bonyolítja. A megoldás a hálózat szempontjából nem transzparens, valamint klasszikus értelemben nem nevezhető csomagszűrőnek, mert a kliens és a server között nem „közlekednek” csomagok. Valahol a csomagszűrők fölött de az alkalmazásszintű tűzfalak alatt helyezkedik el ez a megoldás. <br /> <br /> *'''Alkalmazásszintű tűzfalak:'''<br /> Az alkalmazásszintű, azaz Proxy tűzfalak az első nem csomagszűrési elven működő tűzfalak között. Ez tulajdonképpen a Bastion Host rendszer továbbfejlesztett változata, a Bastion Hostra való bejelentkezésből adódó kényelmetlenségek kiküszöbölése volt az elsődleges feladata. A Proxy működési elve hasonló a Bastion Hostéhoz, a kliens gép és az internetes server között szintén nincs direkt kapcsolat, a serveren(tűzfalon) – ami két hálózati kártyával rendelkezik – fut egy proxy démon, ami kommunikál a klienssel az egyik hálózati csatolón, és az internetes kiszolgálóval a másikon. A kliens „megmondja” a Proxy-nak, hogy milyen erőforrást szeretne elérni a neten, a Proxy kapcsolódik a megadott serverhez és a kapott adatot továbbítja a kliensnek. Ez a megoldás képes kiszűrni a csomagszintű támadásokat. A Proxyk nem csak a csomag fejlécét vizsgálták, hanem képesek voltak betekinteni a csomag adat részébe is, esetleg változtattak is a csomagon. Mivel mélyebben tudja vizsgálni a csomagokat ezért nem okoz problémát a több portot használó alkalmazások tűzfalazása sem mint pl. az [[FTP]], mert „láthatja” hogy mi lehet a következő portcím. A Proxy egyik hátránya, hogy a protokolloknak támogatniuk kell a Proxy-s működést. <br /> <br /> **'''Transzparens Proxyk:'''<br /> A transzparens Proxyk előnye az volt, hogy a már-már áttekinthetetlen konfigurációk helyett egy jóval egyszerűbb megoldást kínált. Az elődjével az volt a legnagyobb probléma, hogy sok alkalmazás nem támogatta, valamint a programonként változó konfigurációból adódóan egyre nagyobb volt az emberi tévedés okozta kockázat. A cél a transzparencia megvalósítása és a Proxyt nem támogató programok kezelése volt. Mivel a tűzfalon, a teljes forgalom áthalad ezért lehetőség volt a csomagszűrőhöz hasonló funkciók ellátására. A működési elve az volt, hogy a kliensen nem kellett Proxy-t beállítani hanem direktben próbáltak kapcsolódni a kiszolgálóhoz, de a tűzfal a csomagokat „elkapja” és magára irányítja. Innentől kezdve pedig úgy működött, mint a nem transzparens Proxy-k. A használata jóval kényelmesebb és rugalmasabb volt elődjénél. Azonban újabb probléma merült fel, mégpedig az összetett protokollok. Ilyen pl. a [[HTTPS]], ami egy [[HTTP]] protokollból és egy [[SSL]] protokollból tevődik össze( pl. Neptun)Tehát muszáj volt a tűzfalak terén is előrelépni, így születtek meg a moduláris Proxyk.<br /> <br /> **'''Moduláris Proxy-k:'''<br /> A tűzfalak ezen vállfaja nem kényelmi okokból, hanem a biztonság növelése érdekében született meg. A moduláris Proxyk rendelkeztek a transzparens Proxy-k minden tulajdonságával, azonban a lényeges különbség az volt, hogy a transzparens Proxy-k minden protokollhoz külön komponenssel rendelkeztek, amik nem tudtak együttműködni. Ezzel ellentétben a moduláris Proxy-k programjai képesek együttműködésre, és a „felesleges” redundanciát is csökkentették(ugyanazon funkciókat több modul is megvalósított). Például a fentebb említett [[HTTPS]] protokoll egy összetett protokoll. A moduláris Proxy esetén van egy [[HTTP Proxy]] és egy [[SSL Proxy]], amik együttműködnek. A bejövő adatokat az [[SSL Proxy]] visszafejti, majd átadja a HTTP Proxynak, ami az adatokat már „sima” http kérésnek értelmezi. Lehetőség van úgymond „beágyazásra” vagy többszintű beágyazásra is, tehát pl. a HTTPS –nél még tartalomszűrést is beiktathatunk. Azt mondhatjuk, hogy ezen tűzfaltípusokkal lehetőség nyílik az eddigi problémák rugalmasabb kezelésére, gyorsabb megoldására. Ahhoz, hogy a Proxy-k képesek legyenek a teljes átmenő forgalom elemzésére és befolyásolására, ismerniük kell az adott protokollhoz tartozó teljes utasításkészletet valamint képesnek kell lennie az átvitt adatok teljes elemzésére. Az előbbit hívjuk mély protokollelemzésnek, az utóbbit pedig content vectoringnak. <br /> Meglepő talán, de a protokollok betartását egyik hálózati eszköz sem ellenőrzi. Mondhatjuk, hogy sajnos de minden hálózati eszközben vannak olyan biztonsági rések, amiket a protokollt „sértő” utasításokkal ki lehet játszani. Ha a Proxy ismeri a protokollra vonatkozó teljes utasításkészletet, akkor észre tudja venni a nem megfelelő utasításokat és megtagadhatja a nem szabványos kapcsolatot. A content vectoring azaz a tartalomszűrés modulként épül be, és általában víruskeresést valósítanak meg segítségével, de előfordul, hogy kulcsszavakra is szűrnek. Jelenleg a moduláris proxy-k kínálják a legmodernebb megoldást a tűzfalak közül.<br /> <br /> =Linkek=<br /> http://www.balabit.hu/common-dl/wps/WP_theevolutionofthefirewall_060626_hu.pdf<br /> <br /> http://en.wikipedia.org/wiki/Firewall_%28networking%29<br /> <br /> =Ajánlott Irodalom Modul=<br /> ''Andrew S. Tanenbaum: Számítógép Hálózatok''<br /> <br /> ''Saját történeti fordítás: http://en.wikipedia.org/wiki/Firewall_%28networking%29''</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C5%B1zfalak&diff=17173 2006-12-14T12:51:04Z

<p>Herher: </p> <hr /> <div>=Történeti Modul=<br /> *'''1980:'''A tűzfal az 1980as évek környékén bukkant fel amikor az Internet egy egészen új technologiaként jelent meg. <br /> *'''1988:''' ''Első generáció a csomagszűrő(Packet filter):''Az első publikált tűzfalas technológia ebben az évben jött létre, amikor Digital Equipment Corporation (DEC)-től ismertetett egy fejlett szűrő rendszert, csomagszűrő tűzfalként. Ez a felbukkant rendszer volt az első generáció. <br /> *'''1980-1990:''' ''Második generáció(Circuit level):''1980 és 1990 között az AT&amp;T Bell Laboratórium két munkatársa, Dave Presetto és Howard Trickey, feltalálta a második generációs tűzfalat amely '''circuit level''' tűzfal néven vált ismertté.<br /> *''Harmadik Generáció (Application Layer) Alkalmazás szintű tűzfal:''Gene Spafford a Purdue Egyetemről, Bill Cheswick az AT&amp;T Laboratóriumból és Marcus Ranum által kitalált harmadik generációs tűzfal: application layer tűzfal vagy másnéven proxy tűzfal.<br /> *'''1992:''' ''Újabb generációk:''Bob Braden és Anette DeSchin a Kelet Kaliforniai Egyetemen(USC) kitalálták a negyedik geneációs csomag szűrő rendszert. A termék mint &quot;Visas&quot; volt az első rendszer amely rendelkezett vizuális felülettel, szinekkel és ikonokkal, amelyek végrehajtották és elfogadták a Microsoft Windows vagy az Apple MacOs-t mint operációs rendszert. 1994-ben egy Izraeli cég amelyet Check Point Software Technologies-nek hívtak, készítette el a FireWall-1 szoftvert.<br /> *'''Proxy:'''A második generációja a proxy tűzfalaknak volt a Kernel Proxy technológia. Ez a tervezés folyamatosan fejlődik, de ez alapvetőleg tagolt és kódolt, jelenleg széleskörűen használják mind a kereskedelemben mind pedig a hazai számítógépes rendszerekben. A Cisco az egyik legnagyobb és legismertebb internetes védelmi cég a világon különösen ennek a cégnek a PIX termékük amelyet 1997-ben publikáltak.<br /> Az új következő generációs tűzfalak hatalma a fennálló alapos csomag vizsgálat az IPS által.<br /> <br /> =Definíciós Modul=<br /> <br /> *'''Csomagszűrés:'''<br /> Ha jobban belegondolunk, két helyen nyílik lehetőség a „teljes” forgalom ellenőrzésére, a felhasználó számítógépén – erre jöttek létre a személyi tűzfalak – vagy a routereknél (útválasztó). Mint a nevéből is kitűnik, a router felelős azért hogy egy csomag a megfelelő célba jusson. Legalábbis kezdetben ez volt a dolguk, de így egy új feladatot is kaptak, méghozzá a csomagok szűrését, kontrollálását és a kapcsolatok felügyeletét, hiszen ez az a „pont” amin a teljes hálózati forgalom keresztülhalad. Ezen csomagszűrési feladat elvégzésére Linux alatt az iptables nevű program nyújtja a talán legérthetőbb és legkönnyebben alkalmazható megoldást. A csomagszűrők három legfontosabb lánccal dolgoznak – ennél azért több van – ezek az input, output, valamint a forward lánc. Az input lánchoz a routerbe beérkező csomagok mennek, az outputhoz a routerből kifelé haladó, a forward lánchoz pedig a két hálózati kártya között haladó csomagok. Minden lánchoz tartoznak szabályok, amelyeket mi adunk meg valamint egy döntés, ami a csomag szabályra való illeszkedése esetén következik be, ezt szintén mi definiálhatjuk.Többféle szűrést is végezhetünk, a legtriviálisabb az [[IP]](ez [[DHCP]] esetében problémás) illetve [[MAC]] címre való szűrés valamint a „kiegészítő információkat”([[TCP]] flageket) is figyelembe tudjuk venni pl [[SYN]], [[ACK]] stb… Lehetőségünk nyílik magasabb rétegbeli(pl. adatkapcsolati réteg) információk alapján is döntést hozni, pl. port alapú szűrést végezni. A legtöbb csomagszűrő lehetőséget kínál – így az iptables is – a [[NAT]](Network Address Translation) elvégzésére ([[PREROUTING]], [[POSTROUTING]] lánc segítségével) valamint naplózásra is. Az előbb említett [[NAT]], tulajdonképpen a hálózati címfordítás pl. adott esetben egy cég egyetlen publikus ip címmel rendelkezik az internet felé, de a hálózat több gépe is kapcsolódik az internetre mégpedig a routeren keresztül, ami elvégzi a címfordítást, azaz kifelé minden gép egy ip cím alól „látszik”. Az egyik hátránya az, hogy nem kínál tökéletes védelmet, mivel csak a csomagok fejlécét vizsgálja és a csomagokat is „egyenként”, nincs lehetőség a [[TCP]] kapcsolat teljes felügyeletére. Az állapottartás hiánya miatt pedig problémás a több porton folyó kommunikáció kezelése mint pl. az [[FTP]] esetében.<br /> <br /> **'''Állapottartó csomagszűrők:'''<br /> A csomagszűrők egyik továbbfejlesztett változata az állapottartó csomagszűrők családja. Az alkalmazások fejlődése megkövetelte, hogy az ismeretlen serverekkel történő kommunikációt is biztonságosabbá lehessen tenni. Erre az elektronikus kereskedelem megjelenésével kimondottan nagy szükség volt. Az állapottartó csomagszűrők egy bizonyos ideig tárolják a beérkező csomagokat, és csak a megfelelő információ birtokában döntenek, úgy, hogy a csomagok közötti összefüggéseket is figyelembe veszik. A tűzfalnak azonosítania kell a kapcsolat kezdetét és végét és ezáltal az ezek között zajló folyamatot. Ezek alapján a kapcsolatba nem illő csomagokat tudja azonosítani. Tehát az állapottartó csomagszűrés az egész kapcsolatot képes vizsgálni, míg az előző csomagszűrési fajta „csak” magát a csomagot vizsgálta. Pédául egy TCP kapcsolat esetén nem csak az [[ACK]] flag megléte, esetleg hiánya, hanem az egész kapcsolat nyomon követése adja meg az információt a döntéshez. A vizsgálatok mélysége között alapvetőleg nincs különbség, hanem csak a kapott információ feldolgozásában. Az állapottartó csomagszűrő meg tudja különböztetni pl. a kapcsolat kiépítését kezdeményező csomagokat valamint annak lezárását kezdeményező csomagokat és már „gyanús lehet számára” ha pl. egy adat csomag megelőzi a kapcsolat kiépülését kezdeményező csomagot. Tehát ez a csomagszűrés az egész kapcsolatot képes felügyelni. Egyébként ezek a csomagszűrők is szabályláncokkal dolgoznak, elődjükhöz hasonlóan. Persze ez a megoldás sem nyújt tökéletes védelmet, gondoljunk csak arra, hogy a csomagszűréssel csak az adott csomag mintegy 5% -át – a csomag fejlécét – vizsgáljuk és a „maradék” 95% mehet tovább, adatként, ami ugye bármit tartalmazhat. A megoldást az alkalmazásszintű tűzfalak vagy proxyk megjelenése jelentette, amelyek a csomagszűrőkkel kb. egyszerre kezdtek fejlődni(párhuzamosan).<br /> <br /> *'''Bastion Host avagy bástya hoszt:'''<br /> A tűzfalak egy következő alternatívája a Bastion Host volt, ami igazából nem teljesen nevezhető tűzfalnak, mert ez tulajdonképpen egy server gép, amire a felhasználók be tudnak jelentkezni és az erőforrásait igénybe tudják venni, egyszerre akár több felhasználó is(multiuseres üzemmód). Tulajdonképpen két kapcsolat van, az egyik a felhasználó és a Bastion Host, a másik pedig a Bastion Host és az internetes server között. Ha a felhasználó valamit el akart érni a neten, akkor előbb be kellett jelentkeznie a Bastion Hostra és azon kezdeményezheti az erőforrás elérését. A felhasználó gépe és a server között nincs direkt csomagkapcsolat. Ez jóval megnehezíti, vagy lehetetlenné teszi a csomagszintű támadásokat. Ettől kezdve már nem a csomagra fogunk koncentrálni, hanem a kapcsolatra, a kapcsolatorientált protokollok miatt is. A tűzfalak képesek lesznek betekinteni a csomagok adat részébe is. A Bastion Host nevű megoldás egy továbbfejlesztett változata a [[Proxy]] illetve a Socks tűzfalak.<br /> <br /> *'''A Socks tűzfalak:'''<br /> A Socks tűzfalak valahol „középen” helyezkednek el a [[Proxy]] és a csomagszűrők között. Csomagszűrőnek nem nevezhetőek, mert a kliens és a server között nem mennek csomagok de alkalmazásszintűnek sem nevezhető mert a hálózati szintre tehető a működése. Ezen megoldások igen rövid életűek voltak. A Socks Proxy lényege az, hogy a felhsználó gépére telepítésre kerül egy program, ami átveszi a hálózati kapcsolatok kezelését az operációs rendszertől. Ha a felhasználó kapcsolódni szeretne egy serverhez, akkor ezt a telepített program intézi, oly módon, hogy kapcsolódik a [[Socks Proxy]] egy adott portjához, és „megmondja” neki, hogy mihez szeretne kapcsolódni. Majd a[[ Proxy]] fog kapcsolódni a kliens által megadott serverhez. A kliens az adatforgalmát a Socks Proxyn keresztül bonyolítja. A megoldás a hálózat szempontjából nem transzparens, valamint klasszikus értelemben nem nevezhető csomagszűrőnek, mert a kliens és a server között nem „közlekednek” csomagok. Valahol a csomagszűrők fölött de az alkalmazásszintű tűzfalak alatt helyezkedik el ez a megoldás. <br /> <br /> *'''Alkalmazásszintű tűzfalak:'''<br /> Az alkalmazásszintű, azaz Proxy tűzfalak az első nem csomagszűrési elven működő tűzfalak között. Ez tulajdonképpen a Bastion Host rendszer továbbfejlesztett változata, a Bastion Hostra való bejelentkezésből adódó kényelmetlenségek kiküszöbölése volt az elsődleges feladata. A Proxy működési elve hasonló a Bastion Hostéhoz, a kliens gép és az internetes server között szintén nincs direkt kapcsolat, a serveren(tűzfalon) – ami két hálózati kártyával rendelkezik – fut egy proxy démon, ami kommunikál a klienssel az egyik hálózati csatolón, és az internetes kiszolgálóval a másikon. A kliens „megmondja” a Proxy-nak, hogy milyen erőforrást szeretne elérni a neten, a Proxy kapcsolódik a megadott serverhez és a kapott adatot továbbítja a kliensnek. Ez a megoldás képes kiszűrni a csomagszintű támadásokat. A Proxyk nem csak a csomag fejlécét vizsgálták, hanem képesek voltak betekinteni a csomag adat részébe is, esetleg változtattak is a csomagon. Mivel mélyebben tudja vizsgálni a csomagokat ezért nem okoz problémát a több portot használó alkalmazások tűzfalazása sem mint pl. az [[FTP]], mert „láthatja” hogy mi lehet a következő portcím. A Proxy egyik hátránya, hogy a protokolloknak támogatniuk kell a Proxy-s működést. <br /> <br /> **'''Transzparens Proxyk:'''<br /> A transzparens Proxyk előnye az volt, hogy a már-már áttekinthetetlen konfigurációk helyett egy jóval egyszerűbb megoldást kínált. Az elődjével az volt a legnagyobb probléma, hogy sok alkalmazás nem támogatta, valamint a programonként változó konfigurációból adódóan egyre nagyobb volt az emberi tévedés okozta kockázat. A cél a transzparencia megvalósítása és a Proxyt nem támogató programok kezelése volt. Mivel a tűzfalon, a teljes forgalom áthalad ezért lehetőség volt a csomagszűrőhöz hasonló funkciók ellátására. A működési elve az volt, hogy a kliensen nem kellett Proxy-t beállítani hanem direktben próbáltak kapcsolódni a kiszolgálóhoz, de a tűzfal a csomagokat „elkapja” és magára irányítja. Innentől kezdve pedig úgy működött, mint a nem transzparens Proxy-k. A használata jóval kényelmesebb és rugalmasabb volt elődjénél. Azonban újabb probléma merült fel, mégpedig az összetett protokollok. Ilyen pl. a [[HTTPS]], ami egy [[HTTP]] protokollból és egy [[SSL]] protokollból tevődik össze( pl. Neptun)Tehát muszáj volt a tűzfalak terén is előrelépni, így születtek meg a moduláris Proxyk.<br /> <br /> **'''Moduláris Proxy-k:'''<br /> A tűzfalak ezen vállfaja nem kényelmi okokból, hanem a biztonság növelése érdekében született meg. A moduláris Proxyk rendelkeztek a transzparens Proxy-k minden tulajdonságával, azonban a lényeges különbség az volt, hogy a transzparens Proxy-k minden protokollhoz külön komponenssel rendelkeztek, amik nem tudtak együttműködni. Ezzel ellentétben a moduláris Proxy-k programjai képesek együttműködésre, és a „felesleges” redundanciát is csökkentették(ugyanazon funkciókat több modul is megvalósított). Például a fentebb említett [[HTTPS]] protokoll egy összetett protokoll. A moduláris Proxy esetén van egy [[HTTP Proxy]] és egy [[SSL Proxy]], amik együttműködnek. A bejövő adatokat az [[SSL Proxy]] visszafejti, majd átadja a HTTP Proxynak, ami az adatokat már „sima” http kérésnek értelmezi. Lehetőség van úgymond „beágyazásra” vagy többszintű beágyazásra is, tehát pl. a HTTPS –nél még tartalomszűrést is beiktathatunk. Azt mondhatjuk, hogy ezen tűzfaltípusokkal lehetőség nyílik az eddigi problémák rugalmasabb kezelésére, gyorsabb megoldására. Ahhoz, hogy a Proxy-k képesek legyenek a teljes átmenő forgalom elemzésére és befolyásolására, ismerniük kell az adott protokollhoz tartozó teljes utasításkészletet valamint képesnek kell lennie az átvitt adatok teljes elemzésére. Az előbbit hívjuk mély protokollelemzésnek, az utóbbit pedig content vectoringnak. <br /> Meglepő talán, de a protokollok betartását egyik hálózati eszköz sem ellenőrzi. Mondhatjuk, hogy sajnos de minden hálózati eszközben vannak olyan biztonsági rések, amiket a protokollt „sértő” utasításokkal ki lehet játszani. Ha a Proxy ismeri a protokollra vonatkozó teljes utasításkészletet, akkor észre tudja venni a nem megfelelő utasításokat és megtagadhatja a nem szabványos kapcsolatot. A content vectoring azaz a tartalomszűrés modulként épül be, és általában víruskeresést valósítanak meg segítségével, de előfordul, hogy kulcsszavakra is szűrnek. Jelenleg a moduláris proxy-k kínálják a legmodernebb megoldást a tűzfalak közül.<br /> <br /> =Linkek=<br /> http://www.balabit.hu/common-dl/wps/WP_theevolutionofthefirewall_060626_hu.pdf<br /> <br /> http://en.wikipedia.org/wiki/Firewall_%28networking%29<br /> <br /> =Ajánlott Irodalom Modul=<br /> ''Andrew S. Tanenbaum: Számítógép Hálózatok''<br /> <br /> ''Saját történeti fordítás: http://en.wikipedia.org/wiki/Firewall_%28networking%29''</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=Szerkeszt%C5%91:Herher&diff=17171 2006-12-14T12:43:21Z

<p>Herher: </p> <hr /> <div>'''Szócikkem''':[[Tűzfalak]]</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=T%C5%B1zfalak&diff=17172 2006-12-14T12:42:57Z

<p>Herher: </p> <hr /> <div>=Történeti Modul=<br /> *'''1980:'''A tűzfal az 1980as évek környékén bukkant fel amikor az Internet egy egészen új technologiaként jelent meg. <br /> *'''1988:''' ''Első generáció a csomagszűrő(Packet filter):''Az első publikált tűzfalas technológia ebben az évben jött létre, amikor Digital Equipment Corporation (DEC)-től ismertetett egy fejlett szűrő rendszert, csomagszűrő tűzfalként. Ez a felbukkant rendszer volt az első generáció. <br /> *'''1980-1990:''' ''Második generáció(Circuit level):''1980 és 1990 között az AT&amp;T Bell Laboratórium két munkatársa, Dave Presetto és Howard Trickey, feltalálta a második generációs tűzfalat amely '''circuit level''' tűzfal néven vált ismertté.<br /> *''Harmadik Generáció (Application Layer) Alkalmazás szintű tűzfal:''Gene Spafford a Purdue Egyetemről, Bill Cheswick az AT&amp;T Laboratóriumból és Marcus Ranum által kitalált harmadik generációs tűzfal: application layer tűzfal vagy másnéven proxy tűzfal.<br /> *'''1992:''' ''Újabb generációk:''Bob Braden és Anette DeSchin a Kelet Kaliforniai Egyetemen(USC) kitalálták a negyedik geneációs csomag szűrő rendszert. A termék mint &quot;Visas&quot; volt az első rendszer amely rendelkezett vizuális felülettel, szinekkel és ikonokkal, amelyek végrehajtották és elfogadták a Microsoft Windows vagy az Apple MacOs-t mint operációs rendszert. 1994-ben egy Izraeli cég amelyet Check Point Software Technologies-nek hívtak, készítette el a FireWall-1 szoftvert.<br /> *'''Proxy:'''A második generációja a proxy tűzfalaknak volt a Kernel Proxy technológia. Ez a tervezés folyamatosan fejlődik, de ez alapvetőleg tagolt és kódolt, jelenleg széleskörűen használják mind a kereskedelemben mind pedig a hazai számítógépes rendszerekben. A Cisco az egyik legnagyobb és legismertebb internetes védelmi cég a világon különösen ennek a cégnek a PIX termékük amelyet 1997-ben publikáltak.<br /> Az új következő generációs tűzfalak hatalma a fennálló alapos csomag vizsgálat az IPS által.<br /> <br /> =Definíciós Modul=<br /> <br /> *'''Csomagszűrés:'''<br /> Ha jobban belegondolunk, két helyen nyílik lehetőség a „teljes” forgalom ellenőrzésére, a felhasználó számítógépén – erre jöttek létre a személyi tűzfalak – vagy a routereknél (útválasztó). Mint a nevéből is kitűnik, a router felelős azért hogy egy csomag a megfelelő célba jusson. Legalábbis kezdetben ez volt a dolguk, de így egy új feladatot is kaptak, méghozzá a csomagok szűrését, kontrollálását és a kapcsolatok felügyeletét, hiszen ez az a „pont” amin a teljes hálózati forgalom keresztülhalad. Ezen csomagszűrési feladat elvégzésére Linux alatt az iptables nevű program nyújtja a talán legérthetőbb és legkönnyebben alkalmazható megoldást. A csomagszűrők három legfontosabb lánccal dolgoznak – ennél azért több van – ezek az input, output, valamint a forward lánc. Az input lánchoz a routerbe beérkező csomagok mennek, az outputhoz a routerből kifelé haladó, a forward lánchoz pedig a két hálózati kártya között haladó csomagok. Minden lánchoz tartoznak szabályok, amelyeket mi adunk meg valamint egy döntés, ami a csomag szabályra való illeszkedése esetén következik be, ezt szintén mi definiálhatjuk.Többféle szűrést is végezhetünk, a legtriviálisabb az IP(ez DHCP esetében problémás) illetve MAC címre való szűrés valamint a „kiegészítő információkat”(TCP flageket) is figyelembe tudjuk venni pl SYN, ACK stb… Lehetőségünk nyílik magasabb rétegbeli(pl. adatkapcsolati réteg) információk alapján is döntést hozni, pl. port alapú szűrést végezni. A legtöbb csomagszűrő lehetőséget kínál – így az iptables is – a NAT(Network Address Translation) elvégzésére (PREROUTING, POSTROUTING lánc segítségével) valamint naplózásra is. Az előbb említett NAT, tulajdonképpen a hálózati címfordítás pl. adott esetben egy cég egyetlen publikus ip címmel rendelkezik az internet felé, de a hálózat több gépe is kapcsolódik az internetre mégpedig a routeren keresztül, ami elvégzi a címfordítást, azaz kifelé minden gép egy ip cím alól „látszik”. Az egyik hátránya az, hogy nem kínál tökéletes védelmet, mivel csak a csomagok fejlécét vizsgálja és a csomagokat is „egyenként”, nincs lehetőség a [[TCP]] kapcsolat teljes felügyeletére. Az állapottartás hiánya miatt pedig problémás a több porton folyó kommunikáció kezelése mint pl. az [[FTP]] esetében.<br /> <br /> **'''Állapottartó csomagszűrők:'''<br /> A csomagszűrők egyik továbbfejlesztett változata az állapottartó csomagszűrők családja. Az alkalmazások fejlődése megkövetelte, hogy az ismeretlen serverekkel történő kommunikációt is biztonságosabbá lehessen tenni. Erre az elektronikus kereskedelem megjelenésével kimondottan nagy szükség volt. Az állapottartó csomagszűrők egy bizonyos ideig tárolják a beérkező csomagokat, és csak a megfelelő információ birtokában döntenek, úgy, hogy a csomagok közötti összefüggéseket is figyelembe veszik. A tűzfalnak azonosítania kell a kapcsolat kezdetét és végét és ezáltal az ezek között zajló folyamatot. Ezek alapján a kapcsolatba nem illő csomagokat tudja azonosítani. Tehát az állapottartó csomagszűrés az egész kapcsolatot képes vizsgálni, míg az előző csomagszűrési fajta „csak” magát a csomagot vizsgálta. Pédául egy TCP kapcsolat esetén nem csak az ACK flag megléte, esetleg hiánya, hanem az egész kapcsolat nyomon követése adja meg az információt a döntéshez. A vizsgálatok mélysége között alapvetőleg nincs különbség, hanem csak a kapott információ feldolgozásában. Az állapottartó csomagszűrő meg tudja különböztetni pl. a kapcsolat kiépítését kezdeményező csomagokat valamint annak lezárását kezdeményező csomagokat és már „gyanús lehet számára” ha pl. egy adat csomag megelőzi a kapcsolat kiépülését kezdeményező csomagot. Tehát ez a csomagszűrés az egész kapcsolatot képes felügyelni. Egyébként ezek a csomagszűrők is szabályláncokkal dolgoznak, elődjükhöz hasonlóan. Persze ez a megoldás sem nyújt tökéletes védelmet, gondoljunk csak arra, hogy a csomagszűréssel csak az adott csomag mintegy 5% -át – a csomag fejlécét – vizsgáljuk és a „maradék” 95% mehet tovább, adatként, ami ugye bármit tartalmazhat. A megoldást az alkalmazásszintű tűzfalak vagy proxyk megjelenése jelentette, amelyek a csomagszűrőkkel kb. egyszerre kezdtek fejlődni(párhuzamosan).<br /> <br /> *'''Bastion Host avagy bástya hoszt:'''<br /> A tűzfalak egy következő alternatívája a Bastion Host volt, ami igazából nem teljesen nevezhető tűzfalnak, mert ez tulajdonképpen egy server gép, amire a felhasználók be tudnak jelentkezni és az erőforrásait igénybe tudják venni, egyszerre akár több felhasználó is(multiuseres üzemmód). Tulajdonképpen két kapcsolat van, az egyik a felhasználó és a Bastion Host, a másik pedig a Bastion Host és az internetes server között. Ha a felhasználó valamit el akart érni a neten, akkor előbb be kellett jelentkeznie a Bastion Hostra és azon kezdeményezheti az erőforrás elérését. A felhasználó gépe és a server között nincs direkt csomagkapcsolat. Ez jóval megnehezíti, vagy lehetetlenné teszi a csomagszintű támadásokat. Ettől kezdve már nem a csomagra fogunk koncentrálni, hanem a kapcsolatra, a kapcsolatorientált protokollok miatt is. A tűzfalak képesek lesznek betekinteni a csomagok adat részébe is. A Bastion Host nevű megoldás egy továbbfejlesztett változata a [[Proxy]] illetve a Socks tűzfalak.<br /> <br /> *'''A Socks tűzfalak:'''<br /> A Socks tűzfalak valahol „középen” helyezkednek el a Proxy és a csomagszűrők között. Csomagszűrőnek nem nevezhetőek, mert a kliens és a server között nem mennek csomagok de alkalmazásszintűnek sem nevezhető mert a hálózati szintre tehető a működése. Ezen megoldások igen rövid életűek voltak. A Socks Proxy lényege az, hogy a felhsználó gépére telepítésre kerül egy program, ami átveszi a hálózati kapcsolatok kezelését az operációs rendszertől. Ha a felhasználó kapcsolódni szeretne egy serverhez, akkor ezt a telepített program intézi, oly módon, hogy kapcsolódik a Socks Proxy egy adott portjához, és „megmondja” neki, hogy mihez szeretne kapcsolódni. Majd a Proxy fog kapcsolódni a kliens által megadott serverhez. A kliens az adatforgalmát a Socks Proxyn keresztül bonyolítja. A megoldás a hálózat szempontjából nem transzparens, valamint klasszikus értelemben nem nevezhető csomagszűrőnek, mert a kliens és a server között nem „közlekednek” csomagok. Valahol a csomagszűrők fölött de az alkalmazásszintű tűzfalak alatt helyezkedik el ez a megoldás. <br /> <br /> *'''Alkalmazásszintű tűzfalak:'''<br /> Az alkalmazásszintű, azaz Proxy tűzfalak az első nem csomagszűrési elven működő tűzfalak között. Ez tulajdonképpen a Bastion Host rendszer továbbfejlesztett változata, a Bastion Hostra való bejelentkezésből adódó kényelmetlenségek kiküszöbölése volt az elsődleges feladata. A Proxy működési elve hasonló a Bastion Hostéhoz, a kliens gép és az internetes server között szintén nincs direkt kapcsolat, a serveren(tűzfalon) – ami két hálózati kártyával rendelkezik – fut egy proxy démon, ami kommunikál a klienssel az egyik hálózati csatolón, és az internetes kiszolgálóval a másikon. A kliens „megmondja” a Proxy-nak, hogy milyen erőforrást szeretne elérni a neten, a Proxy kapcsolódik a megadott serverhez és a kapott adatot továbbítja a kliensnek. Ez a megoldás képes kiszűrni a csomagszintű támadásokat. A Proxyk nem csak a csomag fejlécét vizsgálták, hanem képesek voltak betekinteni a csomag adat részébe is, esetleg változtattak is a csomagon. Mivel mélyebben tudja vizsgálni a csomagokat ezért nem okoz problémát a több portot használó alkalmazások tűzfalazása sem mint pl. az FTP, mert „láthatja” hogy mi lehet a következő portcím. A Proxy egyik hátránya, hogy a protokolloknak támogatniuk kell a Proxy-s működést. <br /> <br /> **'''Transzparens Proxyk:'''<br /> A transzparens Proxyk előnye az volt, hogy a már-már áttekinthetetlen konfigurációk helyett egy jóval egyszerűbb megoldást kínált. Az elődjével az volt a legnagyobb probléma, hogy sok alkalmazás nem támogatta, valamint a programonként változó konfigurációból adódóan egyre nagyobb volt az emberi tévedés okozta kockázat. A cél a transzparencia megvalósítása és a Proxyt nem támogató programok kezelése volt. Mivel a tűzfalon, a teljes forgalom áthalad ezért lehetőség volt a csomagszűrőhöz hasonló funkciók ellátására. A működési elve az volt, hogy a kliensen nem kellett Proxy-t beállítani hanem direktben próbáltak kapcsolódni a kiszolgálóhoz, de a tűzfal a csomagokat „elkapja” és magára irányítja. Innentől kezdve pedig úgy működött, mint a nem transzparens Proxy-k. A használata jóval kényelmesebb és rugalmasabb volt elődjénél. Azonban újabb probléma merült fel, mégpedig az összetett protokollok. Ilyen pl. a HTTPS, ami egy [[HTTP]] protokollból és egy [[SSL]] protokollból tevődik össze( pl. Neptun)Tehát muszáj volt a tűzfalak terén is előrelépni, így születtek meg a moduláris Proxyk.<br /> <br /> **'''Moduláris Proxy-k:'''<br /> A tűzfalak ezen vállfaja nem kényelmi okokból, hanem a biztonság növelése érdekében született meg. A moduláris Proxyk rendelkeztek a transzparens Proxy-k minden tulajdonságával, azonban a lényeges különbség az volt, hogy a transzparens Proxy-k minden protokollhoz külön komponenssel rendelkeztek, amik nem tudtak együttműködni. Ezzel ellentétben a moduláris Proxy-k programjai képesek együttműködésre, és a „felesleges” redundanciát is csökkentették(ugyanazon funkciókat több modul is megvalósított). Például a fentebb említett [[HTTPS]] protokoll egy összetett protokoll. A moduláris Proxy esetén van egy HTTP Proxy és egy SSL Proxy, amik együttműködnek. A bejövő adatokat az SSL Proxy visszafejti, majd átadja a HTTP Proxynak, ami az adatokat már „sima” http kérésnek értelmezi. Lehetőség van úgymond „beágyazásra” vagy többszintű beágyazásra is, tehát pl. a HTTPS –nél még tartalomszűrést is beiktathatunk. Azt mondhatjuk, hogy ezen tűzfaltípusokkal lehetőség nyílik az eddigi problémák rugalmasabb kezelésére, gyorsabb megoldására. Ahhoz, hogy a Proxy-k képesek legyenek a teljes átmenő forgalom elemzésére és befolyásolására, ismerniük kell az adott protokollhoz tartozó teljes utasításkészletet valamint képesnek kell lennie az átvitt adatok teljes elemzésére. Az előbbit hívjuk mély protokollelemzésnek, az utóbbit pedig content vectoringnak. <br /> Meglepő talán, de a protokollok betartását egyik hálózati eszköz sem ellenőrzi. Mondhatjuk, hogy sajnos de minden hálózati eszközben vannak olyan biztonsági rések, amiket a protokollt „sértő” utasításokkal ki lehet játszani. Ha a Proxy ismeri a protokollra vonatkozó teljes utasításkészletet, akkor észre tudja venni a nem megfelelő utasításokat és megtagadhatja a nem szabványos kapcsolatot. A content vectoring azaz a tartalomszűrés modulként épül be, és általában víruskeresést valósítanak meg segítségével, de előfordul, hogy kulcsszavakra is szűrnek. Jelenleg a moduláris proxy-k kínálják a legmodernebb megoldást a tűzfalak közül.<br /> <br /> =Linkek=<br /> http://www.balabit.hu/common-dl/wps/WP_theevolutionofthefirewall_060626_hu.pdf<br /> <br /> http://en.wikipedia.org/wiki/Firewall_%28networking%29<br /> <br /> =Ajánlott Irodalom Modul=<br /> ''Andrew S. Tanenbaum: Számítógép Hálózatok''<br /> <br /> ''Saját történeti fordítás: http://en.wikipedia.org/wiki/Firewall_%28networking%29''</div>

Herher https://miau.my-x.hu/mediawiki/index.php?title=Szerkeszt%C5%91:Herher&diff=17170 2006-12-14T12:40:39Z

<p>Herher: </p> <hr /> <div>Szócikkem:'''''Tűzfalak'''''</div>

Herher