Огляд внутрішнього устройства TCP/IP

Огляд внутрішнього устройства TCP/IP
Цей розділ містить короткий опис TCP/IP в об'ємі, достатньому для подальшого обговорення проблем безпеки, пов'язаних з Інтернетом. [Com91a],[Com91b],[Hunt92] і [Bel89] містять набагато докладніший опис; читачі, які хочуть одержати глибше уявлення, повинні звернутися до цих джерел.
Частково популярність стека протоколів TCP/IP пояснюється можливістю його реалізації на базі великого числа різноманітних каналів і протоколів канального рівня, таких як T1 і Х.25, Ethernet і лінії RS-232. Більшість організацій використовує в своїх ЛВС Ethernet для об'єднання хостов і клієнтських систем, а потім приєднує ці мережі за допомогою T1 до регіональної мережі (наприклад, регіональної магістральної мережі TCP/IP), яка сполучає в свою чергу з мережами інших організацій і іншими магістральними каналами. Як правило, організації мають одне з'єднання з Інтернетом, але великі організації можуть мати два і більш з'єднань. Швидкості модемів збільшуються у міру появи нових комунікаційних стандартів, тому версії TCP/IP, які працюють в середовищі комутованих телефонних каналів, стають все більш популярними. Багато організацій і просто окремі люди використовують PPP (Point-to-Point Protocol) і SLIP (Serial Line IP) для підключення своїх мереж і робочих станцій до інших мереж, використовуючи телефонні канали.
Якщо говорити строго, то TCP/IP - це стек протоколів, включаючий TCP, IP, UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol), і ряд інших протоколів. Стек протоколів TCP/IP не відповідає моделі взаємодії відкритих систем (ВОС), і його структура показана на малюнку 1.1
1.2 IP
Рівень IP одержує пакети, що доставляються нижніми рівнями, наприклад драйвером інтерфейсу з ЛВС, і передає їх лежачим вище рівням TCP або UDP. І навпаки, IP передає пакети, одержані від рівнів TCP і UDP до ніжележащим рівнів.
Пакети IP є дейтаграмамі з негарантованою доставкою, тому що IP нічого не робить для забезпечення гарантії доставки пакетів IP по порядку і без помилок. Пакети IP містять адресу хоста, з якого був посланий пакет, званий адресою відправника, і адреса хоста, яка повинна одержати пакет, званий адресою одержувача.
Високорівневі сервіси TCP і UDP при прийомі пакету припускають, що адреса відправника, вказаний в пакеті, є істинною. Іншими словами, адреса IP є основою для аутентифікації в багатьох сервісах; сервіси припускають, що пакет був посланий від існуючого хоста, і саме від того хоста, чия адреса вказана в пакеті. IP має опцію, звану опція маршрутизації джерела, яка може бути використана для для вказівки точного прямого і зворотного шляху між відправником і одержувачем. Цей шлях може задіювати для передачі пакету маршрутизатори або хости, що звичайно не використовуються для передачі пакетів до даного хосту-одержувача. Для деяких сервісів TCP і UDP пакет IP з такою опцією здається тим, що прийшов від останньої системи у вказаному шляху, а не від свого істинного відправника. Ця опція з'явилася в протоколі для його тестування, але [Bel89] відзначає, що маршрутизація джерела може використовуватися для обману систем з метою встановлення з'єднання з ними тих хостов, яким заборонено з ними з'єднуватися. Тому, те, що ряд сервісів довіряє вказаній IP-адресі відправника і покладається на нього при аутентифікації, дуже небезпечно і може привести до проникнення в систему.
1.2.2 TCP
Якщо IP-пакети містять інкапсульовані пакети TCP, програми IP передадуть їх вгору рівню TCP. TCP послідовно нумерує всі пакети і виконує виправлення помилок, і реалізує, таким чином, віртуальні з'єднання між хостамі. Пакети TCP містять послідовні номери і підтвердження про прийом пакетів, тому пакети, прийняті не в порядку передачі, можуть бути переупорядковані, а зіпсовані пакети повторно послані.
TCP передає одержану інформацію додаткам верхнього рівня, наприклад клієнту або серверу TELNETа. Додатки, у свою чергу, передають інформацію назад рівню TCP, який передає її нижче рівню IP, після чого вона потрапляє до драйверів пристроїв, у фізичне середовище і по ній передається до хоста-одержувача. Сервіси зі встановленням з'єднання, такі як TELNET, FTP, rlogin, X Windows і SMTP вимагають надійності і тому використовують TCP. DNS використовує TCP тільки у ряді випадків( для передачі і прийому баз даних доменних імен), а для передачі інформації про окремих хостах використовує UDP .
1.2.3 UDP
Як показано на малюнку 1.1, UDP взаємодіє з прикладними програмами на тому ж рівні, що і TCP. Проте, він не виконує функції виправлення помилок або повторної передачі втрачених пакетів. Тому UDP не використовується в сервісах зі встановленням з'єднання, яким потрібне створення віртуального каналу. Він застосовується в сервісах типу запит-відповідь, таких як NFS, де число повідомлень в ході взаємодії набагато менше, ніж в TELNET і FTP. У число сервісів, що використовують UDP, входять сервіси на базі RPC, такі як NIS і NFS, NTP(протокол мережевого часу) і DNS(також DNS використовує TCP).
Пакети UDP набагато простіше підроблювати, ніж пакети TCP, оскільки немає етапу встановлення з'єднання (рукостискання).[Ches94]. Тому з використанням сервісів на базі UDP зв'язаний більший ризик.
1.2.4 ICMP
ICMP (Протокол міжмережевих управляючих повідомлень) знаходиться на тому ж рівні, що і IP; його призначення - передавати інформацію, що вимагається для управління трафіком IP. В-основном, він використовується для надання інформації про шляхи до хостам-одержувачів. Повідомлення ICMP redirect інформують хости про існування більш коротких маршрутів до інших систем, а повідомлення ICMP unreachable указує на наявність проблем із знаходженням шляху до одержувача пакету. Крім того, ICMP може допомогти коректно завершити з'єднання TCP, якщо шлях став недоступний. PING є широко поширеним сервісом на базі ICMP.
[Bel89] розглядає дві проблеми з ICMP: старі версії Unix можуть розірвати всі з'єднання між хостамі, навіть якщо тільки одне з них зіткнулося з проблемами. Крім того, повідомлення про перенаправлення шляху ICMP можуть бути використані для обману маршрутизаторів і хостов з метою примусити їх повірити у те, що хост зловмисника є маршрутизатором і пакети краще відправляти через нього. Це, у свою чергу, може привести до того, що атакуючий дістане доступ до систем, яким не дозволено мати з'єднання з машиною атакуючого або його мережею.
1.2.5 Структура портів TCP і UDP
Сервіси TCP і UDP використовуються за допомогою схеми клієнт-сервер. Наприклад, процес серверу TELNET спочатку знаходиться в стані очікування запиту встановлення з'єднання. У який-небудь момент часу користувач запускає процес клієнта TELNET, який ініціює з'єднання з сервером TELNET. Клієнт посилає дані серверу, той читає їх, і посилає назад клієнту відповідь. Клієнт читає відповідь і повідомляє про нього користувача. Тому, з'єднання є двонаправленим і може бути використане як для читання, так і для запису.
Як багато одночасних з'єднань TELNET може бути встановлено між системами? З'єднання TCP або UDP унікальним чином ідентифікується за допомогою чотирьох полів, присутніх в кожному з'єднанні:
IP-адреса джерела - адреса системи, яка послала пакет
IP-адреса одержувача - адреса системи, яка приймає пакет
порт відправника - порт з'єднання в системі-відправнику
порт одержувача - порт з'єднання в системі-одержувачі
Порт - це програмне поняття, яке використовується клієнтом або сервером для посилки або прийому повідомлень; порт ідентифікується 16-бітвим числом. Серверні процеси звичайно асоціюються з фіксованим числом, наприклад числом 25 для SMTP або 6000 для X Windows; номер порту є відомим, оскільки він потрібен, крім IP-адреси одержувача, при встановленні з'єднання з конкретним хостом і сервісом. Клієнтські процеси, з другого боку, запрошують номер порту у операційної системи на початку роботи; і номер порту є випадковим, хоча в деяких випадках він є наступним в списку вільних номерів портів.
Для ілюстрації того, як використовуються порти для посилки і прийому повідомлень, розглянемо протокол TELNET. Сервер TELNET слухає повідомлення, що приходять, на порту 23, і сам посилає повідомлення на порт 23. Клієнт TELNET, на тій же або іншій системі, спочатку запрошує невживаний номер порту у ОС, а потім використовує його при посилці і прийомі повідомлень. Він повинен указувати це номер порту, наприклад 3097, в пакетах, призначених для серверу TELNET, щоб цей сервер при відповіді на повідомлення клієнта міг помістити це номер в посилані їм TCP-пакети. Хост клієнта по прийому повідомлення повинен подивитися номер порту в повідомленні і вирішити, який з клієнтів TELNET повинен прийняти це повідомлення. Цей процес показаний на малюнку 1.2
Малюнок 1.2 Взаємодія при TELNET
Існує достатньо поширене правило, згідно якому тільки привілейовані процеси серверу, тобто ті процеси, які працюють з привілеями суперкористувача UNIX, можуть використовувати порти з номерами менше, ніж 1024( так звані привілейовані порти). Серверу в-основном використовують порти з номерами менше, ніж 1024, а клієнти, як правило, повинні запрошувати непривілейовані порти у ОС. Хоча це правило і не є обов'язковим для виконання і не потрібен специфікацією протоколів TCP/IP, системи на основі BSD дотримують його.
В результаті всього цього брандмауери можуть блокувати або фільтрувати доступ до служб на основі перевірки номерів портів в TCP- і UDP-пакетах і подальшого пропускання через себе або видалення пакету на основі політики, вказуючої доступ до яких служб дозволений або заборонений. (детальніше це описано на чолі 2).
Не всі сервери і клієнти TCP і UDP використовують порти таким простим способом, як TELNET, але в цілому, процедура, описана тут, корисна в контексті брандмауера. Наприклад, багато ОС персональних комп'ютерів не використовують поняття суперкористувача UNIX, але все-таки використовують порти описаним вище способом (хоча немає стандарту, що вимагає це).

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать