Програма сканує DNS-відповіді серверів (цього достатньо, всередині відповідей є запити), і якщо доменне ім'я матчиться з регулярним виразом, друкує адресу з запису А (те, що вийшло в результаті дозволу).
Користуючись цією утилітою можна зібрати майже всю статистику - яке доменне ім'я розрізнялося на IP адресу, і коли це сталося. Підготовлений користувач, звичайно, може сховати цю інформацію (записуючи вузол у hosts-файл, або користуючись іншим каналом для DNS-запитів, наприклад), але для основної маси вузлів ми отримаємо задовільну картину.
Як це працює:
$ sudo ./sidmat eth0 "." iu
Ми бачимо доменні іменаі що вони дозволяються (eth0 - інтерфейс, у якому проходить DNS-трафік).
$ sudo ./sidmat eth0 "." iu | while IFS = read -r line; do printf "%s\t%s\n" "$(date "+%Y-%m-%d %H:%M:%S")" "$line"; done
Фіксуємо час. Залишилося перенаправити результат у файл, і можна скористатися таблицею відповідності. Утиліта може захоплювати DNS-відповіді за допомогою pcap (Лінукс/BSD) або за допомогою механізму nflog в Лінуксі.
Цю ж техніку можна використовувати і для керування трафіком. Фільтрувати за доменом, отримувати адреси доменів з ключовими словамив іменах тощо.
Потрібно мати на увазі, що управління може вийти не дуже обережним. Якщо за час, коли до користувача дійде DNS-відповідь і почне передавати трафік на цей вузол, ми не встигнемо додати адресу в ipset/iptables/таблицю маршрутизації/ще кудись, то трафік піде «звичайним» шляхом.
Крім цього, кваліфікований користувач може генерувати помилкові DNS-відповіді, тобто для репресій краще користуватися цим з обережністю.
Декілька прикладів:
Як отримати список IP-адрес, у яких резолвується vk.com та його піддомени? (Без опції "u" друкуватимуться лише унікальні IP-адреси)
$ sudo ./sidmat eth0 "^vk.com$|\.vk.com$" d
З опціями "d" або "i" видно який саме домен дозволяється в IP-адресу, "d" друкує ім'я домену в stderr.
Як заблокувати адреси, на які дозволяється vk.com, його піддомени та всі домени зі словом odnoklassniki? (Домени типу avk.com не потраплять під правило, odnoklassnikii.com - потраплять).
$ sudo sh -c "/sidmat eth0 "^vk\.com$|\.vk\.com$|odnoklassniki" |/usr/bin/xargs -I() j DROP"
Крім невеликих регулярних виразів можна використовувати списки у файлі (опція «f», другий аргумент інтерпретується як ім'я файлу, його вміст – як один великий регулярний вираз). Списки можуть бути досить великими, ми дивилися на продуктивність списку доменів РКН (трафік на заборонені домени перенаправлявся в VPN), звичайний ПК-маршрутизатор цілком спокійно з цим впорався.
Ви можете допомогти і переказати трохи коштів на розвиток сайту
4601 ,З того часу, як був розвіяний міф про анонімність в інтернеті, питання конфіденційності користувача поповнило список найзлободенніших. Відстежувати вашу діяльність у мережі можуть не лише пошукові системиі відвідувані сайти, а також ваші власні постачальники інтернет-послуг. Технічно це не так вже й складно, якщо DNSвидається вам провайдером, а так найчастіше буває, що весь проходить по DNSтрафік може бути ним відстежений, тим більше, що DNS-запити надсилаються незашифрованим з'єднанням.
Зрозуміло, що заміна перехоплених пакетів не складе особливих труднощів навіть при використанні вами VPN-Сервісів.
Закрити дірку можна лише шляхом шифрування DNS-трафіку, але для цього вам знадобиться спеціальне програмне забезпечення, оскільки жодна з операційних системне підтримує шифрування DNSз коробки. Найбільш простим інструментомдля шифрування DNS-трафіку є - невелика безкоштовна утиліта, вигідно відрізняється тим, що не потребує додаткових налаштуваннях, А значить може використовуватися новачками. Є консольний інструмент DNSCrypt Proxy, але з ним треба возитися - виконувати серію команд у PowerShell, змінювати адресу DNSвручну і таке інше. У кого є час та бажання, будь ласка, можете ознайомитися з ним на сторінці github.com/jedisct1/dnscrypt-proxy .
Ми ж пропонуємо використовувати більш просту та зручну десктопну версію DNS-шифрувальника. Завантажте з сайту розробника simplednscrypt.orgвідповідну вашій розрядності ОС версію програми та встановіть.
Укомплектована легким інтуїтивно зрозумілим інтерфейсом та ще й російською мовою, так що ви легко розберетеся що до чого. Основні налаштування виконуються у розділі "Меню". Щоб почати користуватися програмою, одразу після встановлення натисніть кнопку «Застосувати», а потім виберіть внизу вашу мережну карту, вона має бути відзначена галочкою, як показано на скріншоті. Перемикач "Служба DNSCrypt"має бути активним.
Перевірити, чи все працює неважко. Виконайте у віконці Runкоманду ncpa.cpl, відкрийте властивості вашого підключення, виберіть у списку IP версії 4 (TCPIPv4)та відкриєте його властивості. Радіокнопка "Використовувати наступні адреси DNS-серверів"повинна бути активною, а в полі повинен бути вказаний DNS-Сервер. У нас це 127.0.0.1 , у вас адреса може бути іншою.
За промовчанням програма автоматично вибирає найшвидший сервер, але ви можете змінити переваги, вибравши його самостійно в розділі .
Параметри розділу можна не змінювати, якщо ви не використовуєте протокол IPv4. У загальних налаштуваннях можна увімкнути додаткові вкладки «Чорний список доменів», «Журнал блокування доменів», але це знову, якщо ви збираєтеся працювати з пропонованими в них функціями, зокрема складати «чорні»списки доменів.
Привіт усім! Настав час подивитися на трафік DNS через збільшувальне скло WireShark-а.
Нагадую, що протокол DNS служить для перетворення зрозумілого людям символьного імені, такого як, наприклад, сайт в IP-адресу, на яку виконується запит.
Качаємо файл трафіку. Відкриваємо його у WireShark і дивимося:
Як бачимо, протокол DNS (у виділеній зоні він найнижчий – domain name system) є надбудовою в протокол UDP, що лежить на 4-му рівні. Тобто без встановлення постійного з'єднання, а простою відправкою пакетів (дейтаграм). Як і TCP, протокол UDP має порти. Для DNS це порт із номером 53, що легко простежується у дереві протоколів.
Спускаємось ще нижче, UDP протокол спирається на IP – протокол передачі між мережами. Нині – основний протокол передачі у мережі Internet. На цьому рівні ми маємо інформацію про IP-адреси джерела та призначення. Ну і так само відомості про інкапсульований пакет UDP.
Як адреса джерела буде наша машина (яка запитає інформацію по DNS), а як IP адреса призначення – сама DNS сервер, який (мається на увазі) повинен мати базу даних таких відповідностей.
У цій базі даних зберігаються записи кількох видів:
- A (host) – пов'язує ім'я вузла та його IP адресу;
- AAAA (host) – пов'язує ім'я вузла та його IPv6 адресу;
- CNAME (alias) – пов'язує ім'я вузла та його псевдонім, для перенаправлення інше ім'я вузла;
- MX (mail exchange) – вказує на IP адресу поштового сервера, Що обробляє цей домен;
- NS (name server) – вказує на DNS-сервер, який обслуговує цей домен;
- SOA (start of authority) – вказує на початкову зону для цього домену, містить IP основного DNS-сервера, адресу та контактні дані особи, власника домену, тимчасові мітки тощо;
- PTR (pointer) – покажчик на зворотний зв'язок, Перетворюючу IP адресу в канонічне ім'я;
- SRV (server) – покажчик різні послуги;
- Повний список записів можна переглянути на http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
Отже, повернемося до нашого запиту. Розглядаємо перший пакет:
Як бачимо, якщо розгорнути дерево інформації в аналізі пакета, то видно, що надійшов запит (Queries), отримання стандартного запису хоста (Type: A) на ім'я (Name: www.iana.org). Тобто в перекладі з DNS російською буде так:
“Гей, 68.87.76.178 ! Скажи мені, який IPу чувака на ім'я www.iana.org, хочу йому дещо повідомити”.
Ось такі у них розмови протікають. На що сервер йому відповідають (пакет №2):
Тут ми бачимо відповідь на запитання. Інакше кажучи, DNS-сервер відповідає хосту, що надіслав запит:
“Гей, 71.198.243.158 , ти запитував яку адресу у www.iana.org, так ось, його адреса 192.0.34.162 !, Тепер пиши йому прямо”
Детально тут також слід звернути увагу на поля Flags, які показують характеристики запитів і відповідей:
Тут я знову звернувся до першого пакету, в якому відбувається запит на сервер.
Зверніть увагу на Transaction ID: Це числове значення має повторитися у відповіді, що означатиме відповідь саме на цей запит.
Стандартне двобайтове поле, значення якого складаються з біт:
- перший біт (1) показує, що це запит;
- 2-5 біти (4) – це стандартний запит;
- 7 біт (1) – це не обрізаний запит;
- 8 біт (1) – рекурсивний запит (тобто якщо наш ДНС-сервер не знає IP хоста, який ми запросили, він сам уже опитуватиме інші DNS-сервера, доки не знайде відповідь;
- 10 біт (1) – зарезервований;
- 12 біт (1) – приймати неавторитетні відповіді. Авторитетною називається відповідь від сервера, якщо той заявляє, що сам обслуговує цю зону. Якщо сервер отримав відповідь від інших серверів, то така відповідь для нас є неавторитетною.
Тепер розглянемо прапори відповіді:
Зверніть увагу на ID транзакції. Вона збігається з ID попереднього пакета.
- Перший біт (1) – що це відповідь;
- 2-5 біти (4) – стандартна відповідь;
- 6 біт (1) - авторитетність відповіді, якщо сервер сам обслуговує цю зону - повернеться "1", якщо отримав відповідь з іншого місця - буде "0";
- 7 біт (1) – укорочений пакет. На той випадок, якщо відповідь не міститься у розмірі UDP датаграми (512 байт);
- 8 біт (1) – бажано використання рекурсивних запитів. Якщо прапор стоятиме в “0”, то у відповіді клієнт отримає список інших серверів, від яких може спробувати дізнатися потрібну інформацію.
- 9 біт (1) - сервер робить рекурсивні запити;
- 10 біт (1) – зарезервований;
- 11 біт (1) – отримано авторитетну відповідь, тобто сервер сам обслуговує цю зону;
- 12 біт (1) – приймати неавторитетні відповіді?
- 13-16 біти (4) – код помилки. Якщо 0, то все гаразд.
Ну в цілому розібралися зі стандартними запитаннями-відповідями щодо DNS.
До речі, існував троян, який викрадав дані з комп'ютера, надсилаючи їх як DNS-запитів на сервер. Уявляєте, як це. Більшість файрволлів дозволяє DNS, адже це нормальна робота клієнтського комп'ютера. А хробак під виглядом DNS-запитів відсилав на "лівий" DNS-сервер приватні дані. Мовляв, "Гей, сервер господаря, скажи мені IP вузла з ім'ям "пошта [email protected], пароль yyyyy”?”. А сервер фіксував запити і міг відправляти відповіді, що нічого не значили, тим самим записуючи всі запити в якийсь файл. Кількість DNS-запитів була великою і під їх виглядом можна було передати мегабайти даних абсолютно непомітно для користувача. Якщо спеціально не прослуховувати трафік, виток даних виявити не реально.
