за да разберат всички, че е необходимо да се пачнат срещу нея.
Терминология
Преди да разкажем как работи DNS сървъра и протокола за комуникация трябва да обясним няколко термина.
Зона:
Това е цяла "област" която управлява IP адреси и имена от областта. Като например областта "unixwiz.net" която управлява "www.unixwiz.net" и "mvp.unixwiz.net" които са хостове от тази област.
Неймсървър (nameserver) или DNS сървър: Това е софтуера който управлява областите към който пристигат заявките "Дай ми на този хост IP адреса". Има много и най - различни видове DNS софтуер: BIND, PowerDNS, djbdns ...
Оторитативен неймсървър: Тъй като някой трябва да държи файлът със зоната и да я управлява то той се нарич "мастер" (master) на зоната и той може да я разпространява на "слейв" (slave) съвърите, които заедно с него са оторитативни за самата зона. Всички те отговарят за нея и който от тези сървъри се попита за тази зона те могат да отговорят.
Резолвър: (Resolver) Това е клиентската част на DNS сървъра. Това е програмата която пита "Кой е IP адреса на unixwiz.net?". Всъщност резолвъра е малка библиотека която гледа кои са DNS сървърите които може да пита. А вече всяка програма като FireFox, ICQ, SKYPE използва библиотеката и трансформира имената в адреси.
Рекурсивен неймсървър: Това е сървър който ходи в интернет и намира резултати за зони за които не е оторитативен. (Едно ISP може да дава услуга за клиентите си)
Ресурсен запис : Естествено, че не само име към IP адрес може да питаме един DNS сървър, който се нарича "A record". Има много други записи като: NS (nameserver), MX (mail exchanger), SOA (Start of Authority).
Да направим една проста заявка
За да разберем как работи цялата работа трябва да разберем отгоре до долу в много подробен вид всички полета в заявките на DNS сървърите.
На картинката можем да видим как потребител пингва уеб сайта http://www.unixwiz.net. Както виждате програмата пинг трансформира името http://www.unixwiz.net във IP адреса 8.7.25.94. Но като един потребител не ни е необходимо да знаем като въведем http://www.unixwiz.net в уеб браузера как точно се осъществява трансформацията а просто да знаем името което ни трябва.
1. Каква е схемата:
Потребител пита нейм сървъра на доставчика си за A рекърда на http://www.unixwiz.net. DNS сървъра на доставчика гледа в своите зони и вижда, че не е оторитативен и знае трябва да излезе в интернет да го потърси.
2. Root DNS сървъри
Всички рекурсивни неймсървъри са преконфигурирани със списък от 13 Root (главни) неймсървъри. Тези IP адреси не се менят толкова често.
Root hints
A.ROOT-SERVERS.NET. IN A 198.41.0.4
B.ROOT-SERVERS.NET. IN A 192.228.79.201
C.ROOT-SERVERS.NET. IN A 192.33.4.12
...
M.ROOT-SERVERS.NET. IN A 202.12.27.33
3. Global .NET
Когато Root сървърите не могат нищо да кажат за зоната unixwiz.net те изпращат автоматично запитването към сървърите които отговарят за зоната ".net".
.NET referrals
/* Authority section */
NET. IN NS A.GTLD-SERVERS.NET.
IN NS B.GTLD-SERVERS.NET.
IN NS C.GTLD-SERVERS.NET.
...
IN NS M.GTLD-SERVERS.NET.
/* Additional section - "glue" records */
A.GTLD-SERVERS.net. IN A 192.5.6.30
B.GTLD-SERVERS.net. IN A 192.33.14.30
C.GTLD-SERVERS.net. IN A 192.26.92.30
...
M.GTLD-SERVERS.net. IN A 192.55.83.30
Където дадените ни данни освен имената на съврърите ни се дават и "glue" записи които описват имената на неймсървърите. Това ни позволява да не ги резолваме.
4.
Тогава заявката се засилва към произволен неймсървър от списъка и се пита "Какъв е IP адреса на http://www.unixwiz.net?
5.
Но тези сървъри не знаят нищо за този хост и могат да ни помогнат със зоната на unixwiz.net
unixwiz.net referral
/* Authority section */
unixwiz.net. IN NS cs.unixwiz.net.
IN NS linux.unixwiz.net.
/* Additional section - "glue" records */
cs.unixwiz.net. IN A 8.7.25.94
linux.unixwiz.net. IN A 64.170.162.98
където са описани неймсървърите които отговарят за тази зона.
6.
Още веднъж ние питаме съответните нейсървъри за този адрес към някой от двата неймсървъра. Тези неймсървъри вече са оторитативните за суответната зона.
7.
Неймсървърите ни връщат отговор за адреса за който питаме.
8.
След като имаме отговора. DNS сървъра на ISP-то го праща обратно на клиента.
Но забележете че отговора не съдържа "оторитативен" индикатор което го прави не оторитативен отговор.
---------------------------------------
Тези заявки текат по няколко стотин милярда пъти на ден и обхождат всички неймсървъри по света. Както видяхме по схемите някой който иска да си направи домейн BankOfSteve.com освен че трябва да си сложи неймсървъри, а също трябва да ги индексива в глобалните на съответната зона ".com".
Какво е DNS пакет?
За да вникнем по дълбоко ще обясним какво представлява DNS пакета.
Source / Destination IP адрес
Това рефлектира върху IP адреса на машините които ще изпращат и получават заявките. Възможно е да се променя source адреса но безсмислено destination.
Source / Destination port numbers
DNS сървърите слушат за заявки на порт 53 по UDP или TCP. Destination порта принципно винаги е 53 по UDP а source порта може да варира и е над 1024.
Query ID
Това е уникален номер на заявката за да могат двата неймсървъри да се разберат за коя заявка става въпрос. Един неймсървър може да има много заявки. Понякога му казват Transaction ID (TXID)
QR (Query / Response)
Единица ако е заявка от клиент или 0 ако е отговор от сървър
Opcode
0 ако е стандартна заявка. Другите случаи няма да разглеждаме.
AA (Authoritative Answer)
1 ако е оторитативен отговор и 0 ако не е.
TC (Truncated)
1 ако сървъра не може да побере заявката в 512 байта по UDP и затова клиента трябва да изпрати заявката по TCP.
RD (Recursion Desired)
1 ако е необходима рекурсия и трябва да се допитат всички сървъри във веригата.
RA (Recursion Available)
1 сървъра връща ако има възможност 0 ако не може или не поддържа
Z — reserved
Резервирано и е винаги 0
rcode
Индикира дали е успешно или не запитването
Question record count
Клиента попълва полетата за запитването Име, запис - A, NS, MX и тип IN=Internet при което сървъра повтаря запитването и почти винаги е единица.
Answer/authority/additional record count
Ще обясним малко по късно
DNS Question/Answer data
Съдържат заявката и отговорът. Ще ги обясним по късно.
------------------------------------------------
Типове записи
DNS е една огромна база от данни която съдържа имена типове и стойности. Ще разгледаме най - използваните типове. Останалите типове или за експериментални или не се използват.
Тип - Описание
A - Това е саписа на хост-а. Трансофмрирането на име към IP адрес.
NS - Запис за неймсървър. Името на неймсървъра който държи зоната.
MX - Mail Exchanger е името на мейл сървъра който държи пощата на съответната зона [email protected]
SOA - Запис в който се описва e-mailа на администратора, какви да са времената за ъпдейт на зоната и т.н.
CNAME - Alias или синоним на хост.
TXT - Коментари по зоната, както и записи за предотвратяване на спам (SPF)
Един пример който можем да дадем е хост с два IP адреса:
http://www.example.com. IN A 192.168.1.3
http://www.example.com. IN A 192.168.7.149
Този уеб сървър има 2 IP адреса в зоната и е описан като A запис в IN - INternet класа. Реално само този клас можем да видим. Останалите Chaos или Hesiod можем да ги видим в други имплементации и съвсем частни случаи.
---------------------------------------
Реалната заявка
След като знаем стъпките описани по - горе 4,5,6,7
Въпроса е един: "Кой е адреса на http://www.unixwiz.net?
Принципно ISP сървъра ще върне RD=1 когато може да направи рекурсивно търсене или 0 ако не може.
Портовете остават същите.
И Query ID-то се инкрементира при всяка една заявка.
2&3
ISP сървъра пита Root сървърите за http://www.unixwiz.net а те връщат .net сървърите (c.gtld-servers.net)
4 клиент към сървър
dnsr1 сървъра на ISPто хваща произволен c.gtld-servers.net сървър и въпроса е същият.
Тъй като това е запитване answer/authorities/additional полетата са празни.
Query ID се инкрементира с вътрешния брояч на сървъра.
5. сървър към клиент
Тъй като GTLD сървърите не знаят отговора на въпроса, връщат неймсървърите на unixwiz.net - cs.unixwiz.net и linux.unixwiz.net.
GTLD сървърите не дават информация само за имената на неймсървърите а също и за IP адресите им.
Те са сложени в A запис така наречаната "glue data". И тъй като не може да даде реалните данни той слага AA=0 че не е оторитативен за тях.
Но ако dnsr1 е много зает сървър и има няколкото стотин хиляди запитвания как той ще разбере че този отговор е за съответното запитване ? - Като гледа съответно в полето с Query ID. Пакети които нямат Query ID за игнорирани.
6. клиент към сървър
В стъпка 5 получихме 2 сървъра. Питаме и тях същото, докато не получим съответните желани данни.
7. Сървър към клиент
И ето че последният отговор пристига. Нетипично за предишните отговори този "answer count=1" и той носи A рекърда с IP адреса. В допълнение AA=1 което означава че това е оторитативен отговор. Ако AA=0 ние си мислим че е даден от кеша на сървъра. Query ID 43562 което съвпада с това на чакащо запитване.
Трябва да се има в предвид, че транзакциите протичат много бързо и цялата тази процедура се изпълнява за по малко от секунда.
А също локалните сървъри имат локален кеш (буфер) с който складират записите за известно време и няма нужда да се правят рекурсивни заявки.
---------------------------------
Какво има в кеша?
След като се получи AA=1 неймсървъра запазва името и IP адреса с кеша на сървъра и така улеснява по нататъшното използване.
Time-To-Live
Към всеки хост и IP адрес съответства време което да стои в кеша. Но не само за хоста ами за цялата зона.
--------------------------------------------
Отравяне на кеша
Тук е момента да опишем как един лош човек пуска пакети на сървъра така, че той да му върне данни различни от тези които притежава.
Как неймсървъра разбира че всеки отговор на пакет е "очакван"?
Отговорът се получава на същият порт от който е изпратен (53 UDP)
Отговорът повтаря въпросът.
Query IDто съвпада със запитването.
Целият разговор се води само заедин домейн и не се говори за различни. пр. BankOfSteve.com
Ако всички условия са наред значи неймсървъра ще зачете отговора като автентичен и ще го приеме в кеша.
Но ако лошият човек може да предвиди отоговорите може да вмъкне друг отговор и да обърка кеша.
Лошият човек първо търси неймсървър който мисли, че е уязвим на атаката, после намира домейн който се държи от този неймсървър. След което се опитва да наруши кеша на DNS сървъра като казва, че http://www.goodsite.com е IP адреса на лошия човек.
Както вече разгледахме тази ситуация трябва много да се налучква за да могат всичките отговори да съвпадат, защото иначе отоговорът е отхвърлян всеки път.
--------------------------
Как да отгатнем Query ID?
Преди време Query IDто се инкрементираше с 1ница всеки път и беше лесно за отгатване в старите DNS сървъри.
А сега можем просто да попитаме:
1. Лошият човек пита неймсървъра за име в зоната която той контролира (test.badguy.com)
2. Root и GTLD сървърите турсят зоната badguy.com и вадят неймсървърите на зоната.
3. Прави се заявка към сървърите на badguy.com и тъй като това е негова машина разбира какво е Query ID.
---------------------------
Измама верися 1
Със способността си лесно да предвижда Query ID-то лошият човек може да направи много лоши неща, като например да промени http://www.bankOfSteve.com.
1.
Лошият човек прави заявка за сървъра който иска да го промени.
Като се има в предвид,ч е неймсървърите през които го прави имат възможност за рекурсивно търсене.
2а.
Знаейки, че жертвата ще пита сървъра на ns1.bankofsteve.com започва да наводнява със отговори жертвата всички от ns1.bankofsteve.com че уеб сървъра е IP адреса на badguy.
2b&3
ROot& GTLD сървърите връщат връзка към ns1.bankofsteve.com
4
Жертвата пита ns1.bankofsteve.com за http://www.bankofsteve.com със запитване Query ID 1001 с едно повече от предишното.
5
И самият сървър отговаря с Query ID 1001 с единица повече от запитването.
Но ако атакуващият е успял да уцели 1001 във наводняването с пакети, то тогава отговорът на сървъра ще бъде игнориран.
6
Жертвата получава фалшивият IP адрес и го вкарва в кеша.
7
Всяка следваща заявка към http://www.bankofsteve.com ще води към същият адрес.
Как може да се затрудни атаката?
Като се рандомизира Query ID.
-----------------------------
Измамата на Дан
Във простият пример описахме как се опитваме да превземем адреса в крайният стадий.
Дан какво е открил. Открил е да се вдигнем едно ниво по - нагоре и да се преправят оторитативните отговори.
Дан си прави собствена зона bankofsteve.com (никой не може да му попречи, защото .com сървърите не са го вкарали като оторитативен).
Стъпка 1
Лошият човек пита за случайно име от домейна:
www12345678.bankofsteve.com нещо което не би трябвало да го има в кеша.
Стъпка 2а
Както преди лошият човек започва да праща много отговори наведнъж "Аз не знам отговора но може да питаш там"
Ауторитито може да знае за имената на неймсървърите на bankofsteve.com но IP адресите да сочат към адресите на лошият човек.
Вече лошият човек си има собствена зона.
Статията е взета от тук
