$Ringlet: netsec/txt/dns-plan.txt,v 1.2 2004/01/15 15:51:29 roam Exp $ DNS 1. История - защо е нужно: първа причина: IP адреси се помнят трудно - защо е нужно: втора причина: accountability (какво е това 212.122.160.3 и защо се интересува от моя уеб-сървър?) - hosts table - докато мрежата още е била малка; - въвеждане на идеята за DNS за разпределена scaleable поддръжка - защо е нужно: трета причина: разширяема - не само hostname <--> IP addr, а може да пази и друга информация, примерно MX записи, а по-нататък и SRV записи. 2. Какво всъщност е DNS? - термини: resolver в приложението, resolving cache, authoritative server, зона, запис (има различни типове), delegation of authority, delegation chain - "Какво искат жен.. така де, програмите".. или може би потребителите? :) Обяснение на 'запис' - A запис за nedyalkov.com, имащ стойност 193.110.159.36, после MX запис за nedyalkov.com, имащ стойност ns.unixsol.org (по принцип може примерите да се дават и с ringlet.net - www.ringlet.net A 217.75.134.16, ringlet.net MX 0 a.mx.ringlet.net, ringlet.net MX 10 b.mx.ringlet.net). Крайната цел е програмата да получи тази стойност. - записите са групирани в зони; йерархия от зони - всяка зона има authoritative servers, които дават отговори за нея или пренасочват към child zones - пренасочването, започвайки от *.root-servers.net, образува delegation chain, който клиентите следват, докато намерят това, което им трябва - стигнахме до клиентите: в самата програма има resolver библиотека, която търси най-близкия resolving cache. - last but not least: resolving cache, който тръгва от root servers, проследява delegation chain, стига до записа, който клиентът му е поискал, и cache-ва информацията за следващо ползване. Какво значи time-to-live и защо е адски важно... защо не трябва да бъде прекалено голямо, защо не трябва да бъде прекалено малко - двата режима на работа на resolving cache: да тръгне от root servers или да пита за почти всичко друг cache с по-добра свързаност към И'нет. - AXFR - прехвърляне на цели зони между authoritative servers или от auth server към любопитен клиент 3. Настройка на resolvers - какво трябва да се настрои: 1. адреса на resolving cache, 2. search domains, 3. search order (само да се спомене; сега говорим за DNS, можем да оставим yellow pages и дори hosts леко настрана) - под Unix: /etc/resolv.conf с лесен синтаксис - под Windows: Control Panel >> Network >> TCP/IP.. >> Properties или (по-простичко, read-only) с winipcfg за старите и с ipconfig /all за новите версии на Windows. - разликата между 'www.cnn.com' и 'www.cnn.com.' с точката накрая, и защо първото може да ни доведе примерно до 'www.cnn.com.atlantis.bg, ако не фнимафаме :) - при всички случаи е възможна автоматизирана настройка чрез DHCP. 4. Настройка на resolving caches - какво трябва да се настрои: 1. размер на кеша, 2. authoritative servers за познати (близки) зони, 3. друг resolving cache или директно адресите на root servers. - защо не е добра идея да обясняваме на resolving caches, че "нашите" зони са на "нашите" сървъри: да, може малко да ускори първите два lookups, но след това можем да изпаднем в смешната ситуация да си мислим, че всичко е наред, а всъщност зоните ни да са expire-нали и никой освен нашите caches да не може да ги види. 5. Настройка на authoritative servers - какво трябва да се настрои: 1. за кои зони е authoritative, 2. metadata за зоните: SOA запис, time-to-live за NXDOMAIN, адрес за връзка с hostmaster-а, 3. authoritative servers, 4. записи в тази зона, 5. адреси на authoritative servers за делегираните под-зони. - кратко обяснение на master/slave (може да се спомене скорошната изцепка на калифорнийците, които обявиха термините master и slave за politically incorrect), може би и кратко споменаване на hidden primaries - кратко, но ВАЖНО споменаване на split-horizon DNS: адски важно за вътрешни мрежи, било то на компанията или на домашната/квартална мрежа. Да, не е чак толкова широко разпространено, но пък е достатъчно добра идея, че хората, които сега обучаваме, да започнат да го правят в бъдеще :) - сигурно има какво още да се каже тук? 6. Атаки върху resolvers - DNS spoofing, както го показахме на демонстрацията: просто, но ефективно. Можеш да избереш точно кои записи да spoof-ваш, така че всичко да изглежда нормално, а да променяш само точно определени неща с точно определена цел. - ако адресите на resolving caches идват през DHCP, атакуващият може да прихване DHCP заявката и да изпрати свой си отговор, съдържащ адрес на неговия си DNS сървър: DNS spoofing in one easy step :) 7. Атаки върху resolving caches - DNS spoofing - приложимо и тук, и дори малко по-страшно. - DNS poisoning - по-"удобно" - правиш го само веднъж, ако успееш, този cache си остава poison-нат чак до края на TTL - напоследък: DNS negative poisoning: не чак толкова полезно, става май само за нещо като DoS атака; може да се спомене, че ще бъде *много* полезно, ако е приложено спрямо mail server, който ползва DNS-based block/blackhole lists. - е.. може да кажем две-три думи и за exploits с изпълнение на код върху сървъра, за които може би ще говорим повече втория семестър :) 8. Атаки върху authoritative servers - DNS spoofing в обратна посока: прихващаме заявките на клиентите към този сървър, или по-точно неговите отговори, и вместо тях изпращаме наши - AXFR flood: изпращане на AXFR заявки, възможно от spoofed адрес, макар че не е много лесно; AXFR и IXFR работят почти изключително върху TCP - AXFR information leak: атакуващият може да се опита да направи AXFR прехвърляне на цялата ни зона, така че от имената на машините да разбере много за вътрешната организация на мрежата и съответно какво къде да атакува От тази и предишната атака можем да се спасим с ограничаване на достъпа до AXFR за нашия authoritative server: или чрез конфигурация на сървъра, или чрез firewall rules. Оставяме само IP адресите, от които наистина има нужда да пускаме AXFR - примерно secondary сървърите - exploits за самите сървъри - неправилна обработка на данните, така че част от данните биват интерпретирани като изпълним код, който може да доведе до това атакуващият да получи пълен контрол над сървъра и оттам нататък към машината 9. Как да се предпазим: от по-голямата част от атаките можем да се предпазим с DNSSEC, само че тук вече *трябва* да споменем, че DNSSEC още не е завършен напълно като протокол/framework/whatever, както и че хората, които се опитват да го завършат, един по един започват да се отказват, и че вече има сериозни съмнения дали изобщо ще го бъде... - От проблемите с exploits можем донякъде да намалим щетите чрез използване на chrooted/jailed сървъри/кешове. 10. Може да кажем две-три думи и за реализациите все пак :) - BIND: най-широко използвана реализация на всички части: stub resolver, resolving cache, auth server. Писан от хора, които са легенди в света на Интернет. Въпреки това - много проблеми в миналото, от време на време проблеми и сега (миналата седмица излезе нов negative DNS poisoning за <= 8.3.6 и набързо изкараха 8.3.7). Опит за пълно пренаписване във версия 9, само че още не се е доказала съвсем, а и за нея имаше едно-две проблемчета преди време. - MS DNS server - djbdns: доста широко използван като resolving cache и auth server, включително и от големи компании. Има реализация и на stub resolver library, само че още никой OS vendor не я е включил в libc или libresolv, основно заради странните идеи на д-р. Бернщайн относно software licensing. - MaraDNS: все по-широко използван като resolving cache и auth server, има си и stub resolver, но още не се е доказал май достатъчно. - други варианти за caching resolvers и auth servers: NSD - http://www.nlnetlabs.nl/nsd PowerDNS - http://www.powerdns.com/ странният name service caching daemon на Solaris и Red Hat. - други варианти за stub resolver libraries: adns - http://www.chiark.greenend.org.uk/~ian/adns/ ares - ftp://athena-dist.mit.edu/pub/ATHENA/ares/ netlib - http://www.mozilla.org/docs/netlib/dns.html 11. Кой раздава DNS domains (зони)? (или мястото му е по-рано?) - top-level domains се управляват от ICANN; root servers на няколко места по света, някои от тях дори са разпределени (anycast май); пример: съвсем наскоро "откриха нов клон" на f.root-servers.net в Русия. (чудя се дали ще е на място тук предположението, че Paul Vixie се занимава с f.root-servers.net само за да може да каже, че под негов контрол е важен за Интернет сървър, който се казва 'fruit servers.net' :) - кои са top-level domains: com, net, org, edu, mil, arpa, info, biz, aero, name, museum... май имаше още едно-две? - освен това ccTLD: country-code top-level domains. - second-level domains: има си registrars за всеки top-level domain, а за някои дори повече от един. Доскоро за повечето не-ccTLD's беше само VeriSign/NetSol/TheEvilEmpireByAnyOtherName, вече им взеха монопола, но още не могат да ги спрат да правят глупости. - може да се спомене register.bg - процедура по регистриране: ще се наложи да си плащаш всяка година или поне от време на време, казваш си името на зоната, казваш си auth servers, и ако те харесат, ти пускат. Ако не, пробваш с друг registrar :) - подновяване: крадене на домейни - cyber-squatting: низши форми на живот, само едно ниво по-високо от spammers.