Вивчення та аналіз мережевих протоколів завжди було важливою частиною роботи у сфері мережевої безпеки і системного адміністрування. Протоколи транспортного рівня, які забезпечують надійну передачу даних між пристроями в мережі, є критично важливими для правильної роботи і безпеки мережевих з’єднань. Wireshark і tcpdump – це потужні інструменти, які дозволяють аналізувати і вивчати протоколи транспортного рівня в мережі. Вони надають можливість спостерігати за обміном даними між пристроями, визначати проблеми, виявляти помилки та вдосконалювати продуктивність мережі. Ця стаття зосереджена на огляді протоколів транспортного рівня і на тому, як Wireshark і tcpdump можуть бути використані для їх аналізу та моніторингу. Ви дізнаєтеся, які саме протоколи входять в цей рівень, як вони працюють, і чому вони є важливими для функціонування мережі.
Також буде описано, як саме Wireshark і tcpdump можуть допомогти фахівцям з мережевої безпеки та адміністраторам моніторити та аналізувати ці протоколи для забезпечення безпеки та ефективності мережі. Розуміння протоколів транспортного рівня та вміння використовувати Wireshark і tcpdump для їх аналізу є важливими навичками для всіх, хто працює у сфері мережевої безпеки та адміністрування. Цей текст допоможе засвоїти основи цих навичок та впровадити їх у роботі для забезпечення надійності та безпеки мережі. У цьому розділі ми продовжимо розгляд окремих протоколів та їх прояв на рівні пакетів. Просуваючись вгору за моделлю OSI, ми розглянемо транспортний рівень і найбільш уживані на цьому рівні протоколи ТСР та UDP.
Кінцевою метою протоколу управління передачею (TCP) є забезпечення надійної доставки даних від однієї кінцевої точки в мережі до іншої. Як визначено в RFC 793, протокол TCP відповідає за відстеження послідовностей даних і усунення помилок, і в кінцевому підсумку забезпечує доставку даних до місця призначення. Протокол TCP вважається орієнтованим на з’єднання, оскільки він встановлює формальне з’єднання перед передачею даних, контролює доставку пакетів і, як правило, намагається формально закрити канали зв’язку в кінці передачі. Багато з найбільш поширених протоколів прикладного рівня використовують протоколи TCP і IP для доставки пакетів до приймача.
Протокол TCP надає різноманітний функціонал, що виражається в складності його заголовка. Як показано на рис. 8.1, заголовок пакета цього протоколу складається з наступних полів.
Вихідний порт. Порт, який використовується для передачі пакета на машині відправника.
Порт призначення. Порт, до якого передається пакет на машині одержувача.
Порядковий номер. Число, яке використовується для ідентифікації сегмента протоколу TCP. Значення, встановлене в цьому полі, гарантує, що жодна частина потоку даних не буде втрачена під час передавання.
Номер підтвердження. Порядковий номер, який, як очікується, буде отриманий в наступному пакеті з іншого пристрою, який бере участь у зв’язку по мережі.
Прапори. Це поле встановлює прапорці URG, ACk, PSH, RST, SYN і FIN для визначення типу пакета TCP, що передається.
Розмір вікна. Розмір TCP-пакета прийому буфера, заданий в байтах.
Контрольна сума. Він використовується для того, щоб заголовок TCP і дані залишалися незмінними, коли вони надходять до одержувача.
Покажчик терміновості (Urgent Pointer). Якщо встановлено прапорець URG, вміст цього поля перевіряється на наявність додаткових інструкцій щодо того, де центральний процесор повинен почати зчитування даних в пакеті.
Параметри (0ptions). Це поле містить додаткові параметри, які можна вказати в пакеті TCP.
Файл перехоплення: tcp _JЮrts . pcapng
Весь зв’язок TCP відбувається tcp_ports між портами джерела і приймача, номери яких можна знайти в кожному заголовку TCP. Порт можна порівняти з роз’ємом на старій телефонній патч-панелі (комутаторі). Оператор телефонної станції (або телефонний оператор) постійно стежив за показниками і штекерними роз’ємами на цій панелі. І як тільки загорівся індикатор дзвінка, телефоніст зв’язався з абонентом, запитав, з ким він хоче поговорити, а потім підключив його до іншого абонента, вставивши кабель зі штепсельним роз’ємом у відповідне гніздо комутатора. Для встановлення сеансу зв’язку необхідно було мати порт відправника (тобто абонента) і порт одержувача (тобто абонента-одержувача). Порти протоколу TCP працюють аналогічним чином.
Для передачі даних в конкретний додаток, запущене на віддаленому сервері або пристрої, TCP-пакет повинен вказати відомий номер порту віддаленого сервісу, куди пакет може бути отриманий. Якщо спробувати отримати доступ до програми на віддаленій машині через інший порт, на якому воно не налаштовано, то обмін даними не відбудеться.
Порт відправника в цій послідовності не так важливий і може вибиратися довільно. Віддалений сервер визначить номер порту, з яким буде здійснюватися зв’язок, з надісланого йому вихідного пакета (рисунок 8.2).
Існує 65535 портів для зв’язку TCP. Всі вони, як правило, діляться на наступні категорії.
Група відомих портів, інакше званих стандартними (або постійними) портами з номерами від 1 до 1023, де число 0 зарезервовано і тому ігнорується. Відомі та добре зарекомендували себе служби зазвичай використовують порти, які належать до групи системних портів.
Група ефемерних портів. Це група портів з номерами від 1024 до 65535, хоча в деяких операційних системах ці обмеження можуть визначатися по-різному. Одночасно через порт цієї категорії може зв’язуватися тільки одна служба, і тому в сучасних операційних системах порти відправника вибираються випадковим чином, щоб відрізнити один сеанс від іншого. Як правило, порти відправника знаходяться з доступного діапазону тимчасових (тобто динамічно призначених) номерів портів.
Як приклад розглянемо пару пакетів TCP з файлу перехоплення портів tcp. RSARPD для ідентифікації номерів портів, що використовуються в них. Цей файл містить мережевий трафік N TT P, перехоплений при перегляді клієнтом двох веб-сайтів. Як вже говорилося раніше, для обміну даними в протоколі HTTP використовується протокол TCP, який є типовим прикладом трафіку TCP.
Перші два значення в шапці першого пакета з цього файлу (рис. 8.3) вказують на порт відправника і одержувача цього пакета. Зокрема, цей пакет відправляється від хоста, розташованого за адресою 172.16.16.128, до хоста, розташованого за адресою 212. 58 .226 .142. Порт відправника має номер 2826, тобто це тимчасовий порт. (Нагадаємо, що порти відправника вибираються операційною системою випадковим чином, хоча їх випадково вибрані числа зазвичай збільшуються.) А порт одержувача має номер 80, тобто це стандартний системний порт, закріплений за веб-серверами, які працюють за протоколом HTTP.
Зауважте, що у Wireshark згадані вище порти мають позначки slc-systalog (2826) та http (80). Додаток Wireshark веде список портів і місць, де вони найчастіше використовуються. Хоча системні порти, як правило, позначаються як найбільш часто використовувані, багато ефемерних портів пов’язані з часто використовуваними службами. Таке маркування портів спеціальними мітками може ввести в оману, а тому взагалі краще його перевизначити, відключивши дозвіл імен на транспортному рівні. Для цього в головному меню виберіть команду Edit4Preferences4Name Resolution і зніміть прапорець Resolve Transport Names назви транспорту). Якщо ви хочете залишити цей прапорець, але хочете змінити порядок певного порту в Wireshark, вам потрібно буде внести відповідні зміни до файлу служб, розташованого в системному каталозі Wireshark. Вміст цього файлу базується на списку поширених портів (приклад редагування файлу для перетворення імен див. у розділі “Використання спеціального файлу hosts” у главі 5, “Додаткові можливості Wireshark”).
Другий пакет надсилається у зворотному напрямку з хоста, що знаходиться за адресою 212. 58. 226.142, хосту, розташованому за адресою 172.16.16. 128 (Рис. 8.4). Як і IP-адреси, порти відправника та нолучателя тепер змінюються місцями.
Як правило, обмін даними по протоколу TCP відбувається наступним чином: номер порту відправника довільно вибирається для передачі даних одержувачу по відомому порту. І як тільки початковий пакет буде відправлений, пристрій віддаленого прийому зв’яжеться з передавальним пристроєм через встановлені порти.
Файл перехоплення з розглянутого тут прикладу містить ще один потік зв’язку. Спробуйте визначити номери портів, обрані в цьому випадку для зв’язку.
Файл перехоплення: tcp _handshake.pcapng
Всі зв’язки TCP повинні запускатися протоколом TCP. RSARPD пов’язаний з встановленням зв’язку між двома хостами. Такий процес служить кільком цілям, серед яких наступні:
Передавальний хост може перевірити, чи готовий приймаючий хост до спілкування.
Передавальний хост може перевірити, чи готовий приймаючий хост отримувати дані через порт, через який передавальний хост намагається зв’язатися.
Передавальний хост може відправити свій початковий порядковий номер приймаючому хосту, щоб обидва хоста могли підтримувати заданий порядок пакетів в потоці.
Процес встановлення зв’язку по протоколу TCP проходить в три етапи, як показано на рис.. 8.5. На першому етапі пристрій, на яке потрібно передати дані (хост А), відправляє TCP-пакет одержувачу (хосту B). Цей початковий пакет не містить нічого, крім заголовків пакетів протоколу нижчого рівня. TCP-заголовок цього пакета містить прапор SYN, а також початковий порядковий номер і максимальний розмір сегмента (MSS), який використовується при подальшому обміні даними. Хост B відповідає на цей пакет, відправляючи аналогічний пакет з встановленими прапорами SYN і ASK і його вихідним порядковим номером. І, нарешті, хост A надсилає інший, останній пакет хосту B з встановленим прапором ASCA. Після завершення цього процесу обидва хости повинні мати всю інформацію, необхідну для правильного спілкування.
Щоб побачити процес, описаний тут, у дії, відкрийте файл перехоплення .rsarpd рукостискання tcp. Для спрощення аналізу пакетів в Wireshark є режим заміни серійних номерів TCP-пакетів відносними числами. Однак для цілей цього прикладу краще скасувати цей режим, щоб дотримуватися порядкові номери пакетів. Для цього виберіть команду Edit4Preferences у головному меню, розгорніть заголовок Протоколи, виберіть параметр TCP, опустіть прапорець «Числа відносних послідовностей» у вікні, що відкриється, і натисніть кнопку OK.
Першим пакетом в цьому перехопленому трафіку є спочатку відправлений пакет SYN (рисунок 8.6). Цей пакет передається від хоста, розташованого за адресою 172.16.16.128 на порту 2826, до хоста, який отримує переданий пакет за адресою 212. 58 .226 .142 на порту 80. Як бачите, цей пакет передає серійний номер 3691127924.
Другим в процесі рукостискання є пакет SYN/ASK з відповіддю від хоста, розташований за адресою 212. 58 .226.142 (рис. 8.7). Цей пакет tayuke містить початковий порядковий номер (233779340) цього хоста та номер підтвердження (3691127925). Номер підтвердження, показаний тут, на один більше, ніж номер послідовності з попереднього пакета, оскільки це поле вказує наступний порядковий номер, який хост очікує отримати.
І остання в процесі триетапної установки зв’язку за протоколом є пакет АСК, що надсилається з Хоста, що знаходиться за адресою 172 .16 .16 .128 (рис. 8.8)., як і слід очікувати, цей пакет містить порядковий номер 36911-27-925, що визначається на підставі номера підтвердження у відповідному полі попереднього пакета.
Зв’язок встановлюється перед кожною послідовністю обміну даними по протоколу TCP. Якщо ви сортуєте великий файл перехоплення в пошуках початку послідовності обміну даними, то його явною ознакою є послідовність пакетів SYN-SYN / ACk-ACk.
Файл перехоплення:tcp _ teardown.pcapng
Більшість привітань у кінцевому підсумку завершується прощанням, а в протоколі ТСР кожен сеанс установки зв’язку – розривом. Зокрема, розрив зв’язку з протоколом ТСР служить для коректного завершення сеансу зв’язку, встановленого між двома пристроями, після того, як вони завершать обмін даними. Цей процес включає чотири пакети і установку прапора FIN для позначення кінця зв’язку та розриву з’єднання. У послідовності розриву зв’язку хост А повідомляє про закінчення обміну даними посилкою пакета ТСР із встановленими прапорами FIN і АСК. На це хост Б відповідає пакетом АСК та передає свій пакет FIN/ACК. В свою чергу, 217 хост А відповідає пакетом АСК, : ~ завершуючи обмін даними. Цей нроцесс наочно показаний на рис. 8.9.
Спостерігати за процесом. Починаючи з першого пакета в перехопленій послідовності (рисунок 8.10), можна помітити, що пристрій, розташований на 67 .228 .110 .120, ініціює відключення шляхом відправки пакета з встановленими прапорцями FIN і ASK.
Як тільки перший пакет буде відправлений, хост, розташований за адресою 172 .16.16.128, відповість пакетом ASK, щоб підтвердити отримання цього пакета, а потім відправить свій пакет FIN/ACk. Процес відключення закінчиться, коли хост, розташований за адресою 67 .228 .110 .120, надішле остаточний пакет до ASC. На цьому обмін даними між двома пристроями закінчиться. Якщо їм потрібно відновити зв’язок, їм доведеться знову виконувати триетапну зв’язок TCP.
Файл перехоплення: tcp _ refuseconnection. pcapnq
В ідеальному випадку кожне з’єднання має відмовитися від підключення. rsarpd коректно завершується запуском процедури розриву з’єднання по протоколу TCP. Однак у реальному світі дуже часто зв’язки раптово розриваються. Наприклад, хост може бути неправильно налаштований, або потенційний зловмисник може запустити програму сканування портів. У таких випадках, якщо пристрій не хоче приймати відправлений йому пакет, воно може відправити TCP-пакет з встановленим прапором RST. Ця позначка використовується для позначення того, що підключення раптово розірвано або спробу підключення відхилено.
Файл перехоплення tcp refuseconnection .rsarpd показує приклад мережевого трафіку, який включає пакет RST. Перший пакет у цьому файлі надсилається хостом, розташованим за адресою 192 .168 .100 .138, щоб спробувати зв’язатися з хостом, розташованим за адресою 192 .168 .100. 1, через порт 80. Що цей хост не знає, так це те, що хост на 192.168.100.1 взагалі не приймає пакети на порту 80, оскільки це маршрутизатор Cisco, який не підтримує веб-інтерфейс конфігурації. Тому немає служби, налаштованої на прийом підключень по цьому порту. У відповідь на таку спробу налагодити зв’язок, хост розташувався за адресою 192 .168 .100 . 1, відправляє пакет хосту, розташованому за адресою 192 .168 .100 .138, заявляючи, що зв’язок не може бути встановлений на порту 80. На рис. На рисунку 8.11 показано, як TCP-заголовок другого пакета може збити цю спробу зв’язку. Зокрема, пакет RST містить не що інше, як встановлені в його заголовку прапори RST і ASK, після чого більше не відбувається обмін даними.
У будь-якому випадку пакет RST припиняє зв’язок, незалежно від того, чи це перша спроба встановити зв’язок, як в даному прикладі, або відправлена в рамках зв’язку хост-хост.
Файл перехоплення: udp _dnsrequest.pcapng
Протокол UDP (User Datagrarn Protoc.ol protocol dnsrequest. RSARPD user datagrams) – ще один протокол четвертого рівня, часто використовується в сучасних мережах. Якщо TCP призначений для надійної доставки даних з вбудованою перевіркою помилок, то метою UDP є забезпечення швидкої передачі даних. Саме з цієї причини протокол UDP не вимагає попереднього підключення і, відповідно, не може гарантувати доставку пакетів при передачі даних. UDP формально не встановлює і не припиняє з’єднання між хостами, як це робить TCP.
Мережевий трафік, що використовує безз’єднувальний протокол UDP, який не забезпечує надійних послуг передачі даних, може, м’яко кажучи, здатися непередбачуваним. І це правильно! В результаті інші протоколи, які використовують UDP як транспортний протокол, зазвичай мають вбудовану підтримку надійної передачі даних або використовують певні функції протоколу
ICMP для підвищення надійності з’єднання. Наприклад, протоколи прикладного рівня DNS і DHCP, які в значній мірі залежать від швидкості пакетів по мережі, використовують UDP як протокол транспортного рівня, але вони також забезпечують перевірку помилок і таймери повторної передачі.
UPD заголовок набагато менше і простіше, ніж розумний TCP headerdnsrequest.pcapng. Як показано на рис.8.12, складається з наступних полів.
Вихідний порт. Порт, який використовується для передачі пакета на машині відправника.
Порт призначення. Порт, на який передається пакет на машині одержувача.
Довжина пакета. Довжина пакета в байтах.
Контрольна сума. Служити гарантією незмінності і дані, коли вони прибудуть до місця призначення.
Файл перехоплення .rsarpd udp dnsrequest містить один пакет. Цей пакет – DNS-3anpoc, який використовує протокол UDP. Якщо розгорнути, то тут можна знайти чотири поля, як показано на рис. 8.13. Дуже важливо пам’ятати, що UDP не забезпечує надійної доставки пакетів. Тому в будь-якому додатку, де застосовується цей протокол, повинні бути вжиті додаткові заходи для забезпечення надійної доставки пакетів, якщо це необхідно. Це зовсім не схоже на протокол TCP, де з’єднання формально встановлено та розірвано, а також є вбудовані інструменти для перевірки успішного результату передачі пакета.
У цьому розділі були представлені протоколи транспортного рівня TCP і UDP. На відміну від протоколів мережевого рівня, протоколи TCP і UDP складають основу більшої частини повсякденного спілкування по мережі, і тому вміння ефективно їх аналізувати грає найважливішу роль у розвитку грамотного аналітика пакетів.
Ми використовували матеріали з книги “PRACTICAL РАСКЕТ ANALYSIS ”, яку написав Кріс Сандерс.
548 
442 
394 
330 
361 
366 
402 