 |
|
| 2013. 5. 26. Sunday | Az Ön IP címe: 184.72.91.94 |
|
|
| 2013. 5. 26. Sunday | Az Ön IP címe: 184.72.91.94 |
Javította a Mozilla Alapítvány a Firefox 16-ban talált hibát, a böngésző új kiadása újból letölthető.
Az FBI kikapcsol egy szervert, így a DNS Changer vírus világszerte több százezer számítógép internetre csatlakozását vágja majd el. Egyetlen kattintással ellenőrizheti, hogy gépe érintett-e.
Újabb tárhelycsomag kedvezményt indítottunk..
A Gratislotto és a mbyte.hu tárhelyszolgáltatás jó együttmûködése lehetõvé tette, hogy most egy egyszeri, 5.000 Forint értékû kuponnal kedveskedhessünk Neked!
A 2008-as évben, ha hálózati biztonságról, hálózati veszélyekrol beszéltek, vagy írtak, akkor talán legtöbbször a DNS gyengeségek, és az ehhez kapcsolódó teendok kerültek szóba. Különösen Dan Kaminsky tavaszi felfedezése, és augusztusi eloadása váltott ki sok eszmecserét, és lázas tevékenységet is: a DNS szoftver gyártók a ,,Kaminsky bug'' nyilvánosságra kerülése elott már elkészítették programjaik javított változatát, és a DNS szerver üzemeltetok túlnyomó többsége frissítette a DNS szerver programját, áttért az új változatra. Ez igen örvendetes, de vannak rossz tapasztalatok is: sok üzemelteto olyan módon konfiguálja DNS szerverét, amely veszélyt jelent saját rendszereire, partnereinek, üzletfeleinek rendszereire és a tág internet közösségre.
Mivel a DNS az internetes infrastruktúra kritikus eleme, a DNS szerverek üzemeltetésénél különös gonddal kell eljárni. Ajánlatos többek között:
A név szervereknek két funkciója van: autoritatív, (mutató) és rekurzív (látó) funkció.
Az internet kezdeti idoszakában:
Azonban megbízhatóbb és biztonságosabb, ha az autoritatív név szerverek senkinek nem nyújtanak rekurzív szolgáltatást, a rekurzív név szerverek csak saját hálózati környeztük számára szolgáltatnak és a zóna transzfert csak a szükséges IP címekre és védett módon (tipikusan a zóna másodlagos autoritatív szerverei felé) engedélyezik.
A rekurzív név szerverek ki vannak téve cache poisoning támadásnak. A ,,Kaminsky bug'' is ezzel kapcsolatos, de már évtizedekkel ezelott is voltak példák ilyen támadásra. Valójában a ,,Kaminsky bug'' ellen hozott intézkedések is csak csökkentik, de nem szüntetik meg a veszélyét annak, hogy a rekurzív név szerverek cache-ét hamis adatokkal mérgezzék. Ha ez megtörténik, akkor nem csak a rekurzív szerver által kiszolgált kliensek, hanem az összes autoritatív DNS adat is veszélybe kerül.
Veszélybe hozza az autoritatív szolgáltatást nem csak a cache mérgezés, hanem minden más támadás is, ami egy rekurzív név szervert érhet (pl. bénító, DoS támadás).
A .hu alatti domain-ok számára gyakran olyan regisztrátorok nyújtanak autoritatív szolgáltatást, akik egyúttal internet szolgáltatók, és így rekurzív név szerver szolgáltatást is adnak ügyfeleiknek. Ismételten elofordultak a következo hibák:
Az ISP1 név autoritatív szerver egyik ügyfele az Csakegypelda Kft. A Kft. számára az ISP1 név szerver szolgáltatást nyújtott, az ns.isp1.hu szerveren. Tehát az ns.isp1.hu autoritatív választ adott a csakegypelda.hu zónára vonatkozóan. Az ISP1 nem választotta szét a rekurzív és az autoritatív funkciót, a rekurzív név szerver, amit ügyfelei használtak szintén az ns.isp1.hu. Valamilyen okból a csakegypelda.hu autoritatív név szerverei átkerültek ISP2 szolgáltatóhoz. Egy adott pillanattól kezdve tehát a csakegypelda.hu név szerverei ns.isp2.hu és ns2.isp2.hu lett. Az átregisztrálás rendben lezajlott, de az ISP1 munkatársai elfelejtették az autoritatív név szervereiken kivenni a konfigurációból a csakegypelda.hu-ra vonatkozó részt. Ennek az a következménye, hogy az ISP1 ügyfelei, akik rekurzív név szerverként használjáka ns.isp1.hu-t, az átregisztrálást nem érzékelik, például nem érik el a csakegypelda.hu web lapját, nem tudnak levelet küldeni a valaki@csakegypelda.hu címekre! Sot, lehet, hogy hibás, elavult web lapot látnak, rossz helyre küldik a leveleket stb. A Csakegypelda Kft. számára az ilyen hiba katasztrófális következményekkel járhat.
A Csakegypelda Kft. az ISP1 hálózata mögött volt. Számára autoritatív és egyben rekurzív név szerver is volt az ns.isp1.hu. A .hu alatti regisztráció megszunt, de az ISP1 munkatársai elfelejtették kivenni az autoritatív név szervereikben a csakegypelda.hu-ra vonatkozó részt. Ebben az esetben a Csakegypelda Kft. sokáig észre se vette, hogy megszunt a regisztráció, hiszen az o hálózatából fel lehetett oldani a csakegypelda.hu neveket!
A konfigurálásnál elkövetett feledékenység nem vezetett volna ilyen hibákhoz, ha az autoritatív és rekurzív funkciók szét lettek volna választva.
A legtöbb manapság használatos DNS szoftverben más program valósítja meg a rekurzív és az autoritatív funkciót. A legnépszerubb szerver program, a Bind azonban lehetové teszi a régi muködést is. Ha autoritatív név szervert üzemeltetünk Bind 9. név szerverrel, akkor a konfigurációjában az opciók között adjuk meg ezt az egy sort:
recursion no;
A Bind kézikönyvben ezt olvashatjuk (1.4.6):
The BIND name server can simultaneously act as a master for some zones, a slave for other zones, and as a caching (recursive) server for a set of local clients.
However, since the functions of authoritative name service and caching/recursive name service are logically separate, it is often advantageous to run them on separate server machines. A server that only provides authoritative name service (an authoritative-only server) can run with recursion disabled, improving reliability and security. A server that is not authoritative for any zones and only provides recursive service to local clients (a caching-only server) does not need to be reachable from the Internet at large and can be placed inside a firewall.
Az 1996-ban kiadott RFC2010 így ír:
Recursion is a major source of cache pollution, and can be a major drain on name server performance. An organization's recursive DNS needs should be served by some other host than its root name server(s).
A 2008-ban kiadott RFC5358:
In general, it is a good idea to keep recursive and authoritative services separate as much as practical.
D.J. Bernstein, akinek népszeru DNS szerver implementációja nem szorult javításra a ,,Kaminsky bug'' felfedezésekor, külön oldalt szentel a szétválasztás szükségességének:
http://cr.yp.to/djbdns/separation.html
Ebben idézi a ,,DNS and Bind'' címu könyvet, ahol az autoritatív szerverekrol ezt olvashatjuk:
You should make sure that these servers don't receive any recursive queries.
Más források, ahol szintén olvashatunk a szétválastás szükségességérol:
Ha egy rendszergazda nyílt rekurzív név szervert (ORN) üzemeltet, akkor akaratlanul szolgáltatásokat nyújthat távoli számítógépek részére, és pazarolhatja saját eroforrásait. Nagyvonalúságának következtében azonban a szolgáltatás bénításának veszélye elsosorban nem is nála, hanem az internet bármely más pontján fennáll.
A nyílt rekurzív névszervereket könnyu felfedezni: elég egy autoritatív név szerver naplófájlját figyelni, és százezer számra lehet rekurzív név szervereket találni. Ha egy-egy hálózatban keresünk rekurzív név szervert, akkor elég a hálózat valamely gépét arra késztetni, hogy oldjon fel nevet az általunk felügyelt domain-ból, amire sok egyszeru és hatásos eszköz van.
Ha egy támadó el akarja téríteni egy gép forgalmát, akkor elég, ha rezolverét átállítja egy nyílt rekurzív névszerverre, és ezt a nyílt rekurzív névszervert megfertozi. Fertozött gépeken a rosszindulatú kód gyakran írja át a rezolvert. Ha ez sok gépen megtörténik, akkor egyetlen fertozött nyílt rekurzív névszerver hatalmas károkat okozhat akár gépek, felhasználók millióinak.
A látó (caching, rekurzív) név szerverekben definiáljunk egy IP cím halmazt, és csak ezek számára nyújtsunk rekurzív feloldást. Ez Bind-ban ehhez hasonló módon teheto meg:
#Felsoroljuk a hálóztokat CIDR formában, ahonnan megengedünk rekurzív kérdéseket: acl "itt" { 127.0.0.0/8; 10.11.12.0/24; }; #Az opciók közt megszorítást teszünk arra, hogy kiknek is akarjuk rekurzív kéréseit kiszolgálni: options { allow-recursion {itt;}; };
Sok eszköz rendelkezésre áll. Például az ISZT-nél a http://deneb2.iszt.hu/~pasztor/cgi-bin/recursive.cgi lapon ellenorizhetjük, hogy egy IP címen nyílt rekurzív név szerver muködik-e.
Az US-CERT anyaga jó magyarázatot, és boséges forrásanyagot tartalmaz: http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf
Zóna transzfert célszeru csak az autoritatív másodlagos (slave) szerverek fele megengedni. A következo konfigurációs fájl részlet csak a 11.22.33.44 és a 11.22.33.45 címre engedi meg a zóna transzfert:
allow-transfer { 11.22.33.44; 11.22.33.45; };
Az allow-transfer opciót megadhatjuk a teljes konfigurációra, vagy egy-egy zónára vonatkozóan. Figyelemmel kell lenni az esetleges rejtett (stealth) autoritatív név szerverekre.
A zóna transzfer biztonságát és megbízhatóságát érdemes növelni TSIG (RFC2845) segítségével. A TSIG egy egyszeru szimmetrikus kulcsú technológia, melynek segítségével a zóna transzfernél a partnerek kölcsönösen autentikálják egymást, és biztosítják az adatátvitel sértetlenségét és hitelességét. Az adatátvitel digitális aláírással védett, és a ,,replay attack'' elleni védekezésül az aláírás a pillanatnyi idotol is függ. Ezért fontos, hogy a szerverek órái szinkronban legyenek. Ha TSIG-et akarunk használni a zóna transzferhez, akkor mindkét oldalon be kell vezetni a közös kulcsot a konfigurációba ilyesféleképpen:
key z_key { algorithm hmac-md5; secret "U2FsdmEgbWUgZm9ucyBwaWV0YXRpc1whCg=="; };
Az elsodleges (master) oldalon az allow_transfer utasításban nem IP címet vagy ACL-t, hanem kulcsot kell megadni:
allow-transfer { key z_key; };
A másodlagos (slave) oldalon pedig a meg kell adni, hogy a master-t milyen kulcs használatával kell elérni:
server 11.11.11.11 { keys z-key; };
Ebben a példában 11.11.11.11 a zóna elsodleges (master) szerverének a címe, amit a zone utasításban használunk.
