Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
[...] és uralkodjatok [...]
mindenféle állatokon. [...]
És nevet ada az ember minden
baromnak, az ég madarainak,
és minden mezei vadnak
/Biblia, Mózes első könyve/
2013. június 26.  
 DNSSEC: Nomen est omen! 
   
Két hír is megjelent nemrég, amelyek DNS-rendellenességekhez kötődtek: a 2013. június 20-án leírtak szerint a LinkedIn DNS bejegyzéseit módosították, két napra rá pedig a .biz tartományról derült ki, hogy rosszak a kapcsolódó kriptográfiai adatok (DNSSEC attribútumok). Az ilyen jellegű "spoofing" kivédésére találták ki a DNSSEC attribútumokat, amelyeket 2011. év elejére sikerült bevezetni minden legfelső szintű tartománynál, sőt, néhány ország (pl. svéd: .se, cseh: .cz) még ennél is gyorsabb volt. Magyarországon (.hu) egyelőre kísérleti üzemben működik egy DNSSEC attribútumokat lekérdező és elemző névfeloldó (sechu.iszt.hu). Mielőtt azonban megvizsgálnánk a "DNSKEY", "DS" és "RRSIG" elemeket, érdemes két bekezdést szánni az alapokra.

A nemzetközi IANA (Internet Assigned Numbers Authority) hatóság felel a különböző tartományok kezeléséért. Mind az általános ("gTLD", "generic top-level domain"), mind az országok szerinti ("ccTLD", "country code top-level domain") legfelső szintű tartományok az IANA alá tartoznak. Léteznek még más legfelső szintű tartományok is, amelyeket külön szoktak emlegetni (pl. ".arpa", ".int"), de ma már alapvetően a "gTLD" és "ccTLD" alá kerülnek az új bejegyzések.


forrás: http://www.iana.org/domains/root/db

A listában szereplő, adott legfelsőbb szintű tartományért ("top-level domain") felelős szervezetek nyújtják a "whois" szolgáltatásokat és gondozzák a mögöttük levő adatbázisokat. A "whois" bejegyzés tartalmazza az adott tartomány ("domain") tulajdonosának és regisztráló szervezetének az adatait.

A "gTLD" kategóriában (amely lehet "sponsored" – sTLD – vagy "unsponsored" – "uTLD") pl. az ".org" tartományt a PIR (Public Interest Registry) képviseli. Egy adott, ".org" alá tartozó tartomány "whois" bejegyzéseit a PIR-hez kapcsolódó "whois.publicinterestregistry.net" kiszolgáló adja vissza.

A "ccTLD" kategóriában pl. a ".hu" tartományt (Magyarországot) az Internet Szolgáltatók Tanácsa, illetve ISZT Nonprofit Kft. (angolul: CHIP, Council of Hungarian Internet Providers) képviseli. Egy adott, ".hu" alá tartozó tartomány "whois" bejegyzéseit az ISZT-hez kapcsolódó "whois.nic.hu" kiszolgáló adja vissza.

A különböző – "gTLD" és "ccTLD" – alá tartozó tartományokat a leendő tulajdonos, előfizető kérésére regisztráló szervezetek ("registrar") jegyeztetik be. Ezen regisztráló szervezeteket az adott "gTLD" vagy "ccTLD" felelős szervezete (pl. ".hu" alatt az ISZT) kell, hogy akkreditálja először és csak utána válnak jogosulttá kérelmek benyújtására.

A regisztráló szervezeteken keresztül a tartomány tulajdonosa, előfizetője meg tudja adni a rendszer architektúra paramétereit is, amelyek a DNS bejegyzésbe kerülnek. Egy új bejegyzés vagy bármilyen módosítás (a rendszer bármelyik szintjén) legkevesebb néhány óra, legfeljebb 5-10 nap alatt terjed szét, frissül az összes kiszolgálónál.

A DNS rekordok leggyakoribb bejegyzései:
  • Az "A" ("Address") bejegyzések tartalmazzák a tartományok ("domain", "subdomain") címeit.
  • A "CNAME" ("Canonical Name") bejegyzések tartalmazzák a tartományok közötti átirányításokat ("alias", "redirect").
  • Az "MX" ("Mail Exchange") bejegyzések tartalmazzák a levelező szerverek címeit.
  • Az "NS" ("Name Server") bejegyzések tartalmazzák a DNS szerverek címeit.
  • A "SOA" ("Start Of Authority") bejegyzések tartalmazzák az adott tartomány legfontosabb adatait (pl. elsődleges DNS szerver, tartománygazda e-mail címe) összegyűjtve.
  • Az "SPF" ("Sender Policy Framework") bejegyzések tartalmazzák a levelek küldésére vonatkozó szabályokat ("spam" elleni védelem, csak belső címről lehet kiküldeni levelet).
  • A "TXT" ("Text") bejegyzések tartalmazzák a megjegyzéseket, de akár más beállításokat is, ha másképpen nincsenek támogatva (pl. "SPF").
A DNSSEC kiegészítés (digitálisan aláírt DNS rekordok) új adattípusokat is meghatároz a bejegyzésekben (az IETF RFC 4034 és IETF RFC 5155 szabványban):
  • A "DS" ("Delegation Signer") bejegyzések tartalmazzák az aláíró kulcsok azonosítóit (az aláíró kulcsok lenyomatait).
  • A "DNSKEY" ("DNS Key") bejegyzések tartalmazzák az aláíró kulcsok másik felét, a nyilvános kulcsokat.
  • Az "NSEC" ("Next Secure Resource") bejegyzések tartalmazzák a következő mérvadó ("authoritative") DNS szerver adatait.
  • Az "NSEC3" ("Next Secure v3") bejegyzések tartalmazzák a következő mérvadó ("authoritative") DNS szerver adatait kriptográfiai lenyomatokkal védetten.
  • Az "NSEC3PARAM" ("Next Secure v3 Parameters") bejegyzések tartalmazzák a következő mérvadó ("authoritative") DNS szerver adatainak kriptográfiai paramétereit (pl. lenyomatképző algoritmus, "salt").
  • Az "RRSIG" ("Resource Record Signature") bejegyzések tartalmazzák az aláírás értékeket.



Ahhoz, hogy valódi DNSSEC adatokat tudjunk elemezgetni, először be kell szerezni őket! Vannak olyan tartományok, amelyek rendelkeznek DNSSEC attribútumokkal (pl. .com), vannak olyan névfeloldók is, amelyek vissza tudják adni és tudják értelmezni ezen attribútumokat (pl. bind.odvr.dns-oarc.net) és vannak olyan felületek, amelyeken keresztül ezeket el is lehet érni (pl. webes lekérdezés, BIND - Berkeley Internet Name Domain - csomag részét képező "dig" segédalkalmazás):
  • http://dnssec-debugger.verisignlabs.com/
  • http://dnsviz.net/
  • http://dnscheck.iis.se/
  • dig @bind.odvr.dns-oarc.net com +dnssec +multiline
  • dig @sechu.iszt.hu hu +dnssec +multiline
  • ...


Ha megvannak az adatok, akkor egyszerűen mentsük le őket! A jelen esetben a "com" tartomány egy "DS" és egy "RRSIG" attribútumát fogjuk megnézni, amelyekhez egy-egy "DNSKEY" elemre is szükségünk lesz (Key ID: 20580 és 30909). A "Flags" értékéből látszik is, hogy a 20580-as kulcs (Flags=256) egy Key Signing Key (KSK), a 30909-es kulcs (Flags=257) pedig egy Zone Signing Key (ZSK).


A "DS" attribútum esetében először nézzük meg, hogy mit is tárol a rendszer, mi az a lenyomat, amit nekünk is valahogy elő kellene állítani!


Természetesen az IETF RFC 4034 részletesen leírja a lenyomatszámítás módját...


... így meg is kapjuk az elvárt értéket (SHA-256) az OpenSSL segítségével.


Az "RRSIG" attribútum esetében több dologra van szükségünk, mint a "DS" esetében! Először ki kell nyernünk az "RRSIG" aláírását létrehozó "DNSKEY" nyilvános kulcs értékét! Ehhez a base64 kódolt értéket kell dekódolni, majd a megkapott RSA kulcs nyilvános paramétereit átrendezve és az ASN.1 szabályainak megfelelő körítést hozzárakva már előáll az OpenSSL által is emészthető formátum.


Az OpenSSL olyan kulcsokat tud használni, amelyek az ASN.1 szabályoknak megfelelnek, ennek ellenőrzésére pedig igénybe tudjuk venni az ASN.1 Editor alkalmazást.


Az "RRSIG" attribútum értékét - a kódolt lenyomatot - dekódoljuk, hogy megkapjuk a PKCS#1 struktúrát, amiben a "padding" mögött foglal helyet a lenyomat (SHA-256). A lenyomat kiszámítása a "DS" attribútumnál leírtakhoz hasonlóan történik.


A PKCS#1 adatstruktúra is megfelel az ASN.1 szabályainak, így ezt is meg lehet nyitni ASN.1 Editor alkalmazással.


A DNSSEC attribútumok által nyújtott védelem viszont csak úgy működik, ha egyrészt ezeket figyelembe veszi a kommunikációban résztvevő összes fél, másrészt a névkiszolgálók oldalán megfelelően gondozzák a kulcsokat és a kriptográfiai attribútumokat. A .biz tartomány mostani - negatív - példája talán felhívja erre a figyelmet...

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info