Тунелювання не-транспортними протоколами

Уявимо собі програміста, який з певних причин проектує протокол обміну даними між двома вузлами мережі, не використовуючи широко відомі транспортні протоколи.

Найбільш типовими причинами для такого підходу до розробки може бути необхідність побудови каналу зв’язку, який не детектується більшістю файрволів на користувацькому ринку. Наприклад, це може легко запустити оболонку командного процесора на віддаленому сервері.

Стандартні стеки TCP/IP в більшості операційних систем відповідають вимогам стандартів RFC для вузлів Інтернет. Ці вимоги визначають набір дій, які стек TCP/IP повинен вчинити кожного разу, коли отримує вхідний пакет. Наприклад, типовий вузол мережі повинен відповісти на вхідний пакет ICMP, оскільки вони використовуються для керування трафіком та уникнення скупчень пакетів, звітування про недосяжність портів, оголошень про нові маршрути тощо.

Складні файрволи, як програмні так і апаратні, можуть застосувати додатковий рівень інтелектуальності обробки шляхом фільтрації пакетів ICMP у відповідності з їх типом.

Відомо, що пакети ICMP можуть бути використані для атаки на вузол мережі, для того, щоб викликати відмову обслуговування (DoS) або щоб відвернути цінний трафік на сторонній вузол.

Один з прикладів того, як працює ця фільтрація, є блокування вихідних «ехо-відповідей». Один з перших кроків, які до цього часу застосовують зловмисники для визначення того, що певний вузол знаходиться в мережі, це надсилання йому «ехо-запиту». Тому блокування «ехо-відповідей» теоретично приховує цільовий вузол від виявлення. Корисність цього способу викликає певний сумнів, оскільки «ехо-запит» не є єдиним способом визначення наявності вузла в мережі.

Кожен раз, коли такий тип блокування НЕ задіяний на вузлі, на якому запущене програмне забезпечення для тунелювання через ICMP, стек TCP/IP обробляє всі вхідні ICMP пакети. Це додає певної складності для програмного забезпечення, призначеного для побудови довільного каналу зв’язку, оскільки драйвер TCP/IP операційної системи, скоріше за все, буде відповідати самостійно на «ехо-запити» до того, як клієнтська сторона тунелю матиме шанс відреагувати.

Можливим рішенням цієї проблеми була б можливість для клієнтської сторони тунелю блокувати пакети «ехо-відповіді», які згенеровані операційною системою. Для того, щоб не порушувати нормальну роботу вузла в мережі, не всі вихідні пакети ICMP мають бути заблокованими, а лише ті, які спрямовані на серверну сторону тунелю та згенеровані у відповідь на пакети «ехо-запиту», що несуть інформацію тунелю.

Комбінуючи методи, показані в циклі статей щодо програмування драйверів режиму ядра в середовищі Borland Delphi з документацією з розробки програмного забезпечення для Microsoft Windows, можна побудувати допоміжний драйвер у відповідності з інтерфейсом системного IP-фільтра. Цей драйвер перевіряє кожний вихідний пакет ICMP перед тим як він вийде з мережевого інтерфейсу. Якщо призначення пакету — серверна сторона тунелю, то пакет пропускається лише при дотриманні певних вимог, які задаються програмним забезпеченням клієнтської сторони на тому ж самому вузлі.

На протязі ранніх етапів розвитку Інтернет не було проблем, пов’язаних з так званим вичерпанням адресного простору IP. Адреси тоді роздавалися за принципом мережевих класів досить широко, іноді з перевищеними вимогами. Сьогодні, близько 70% адресного простору вже зайнято, включаючи приватні, немаршрутизовані та мультикастові діапазони.

Це призвело до появи кількох методик, що дозволяють мережевим вузлам працювати в Інтернет, розділяючи лише одну публічну IP-адресу. Ці методики включають в себе сервери Proxy та Socks, трансляцію мережевих адрес (Network Address Translation) тощо. Остання особливо важлива при розгляді питань про тунелювання трафіку.

NAT-шлюз це вузол мережі, у якого мінімум два мережевих інтерфейси — один під’єднаний до публічної мережі (звичайно це Інтернет), інший до приватної (звичайно, корпоративна мережа або інший мережевий сегмент з немаршрутизованими адресами).

Встановлений як шлюз за замовчаням, NAT-шлюз приймає пакети, спрямовані назовні, вносить корективи в структуру пакетів, та відправляє їх з публічного інтерфейсу. Якщо приходить відповідь, за допомогою внутрішніх таблиць перетворення шлюз вирішує, до якого з попередних пакетів надійшла дана відповідь. Потім шлюз робить зворотні перетворення службової інформації в пакетах та надсилає пакет з приватного інтерфейсу.

На сьогодні, технологія NAT використовується не тільки для прозорого доступу користувачів до мережі Інтернет, але також для публічно доступних серверів Інтернет. В останньому випадку, спеціальні заходи типу «перенаправлення портів» вживаються для досягнення видимості сервера ззовні.

Якщо дещо заглибитися в внутрішні алгоритми роботи реалізацій NAT, доступних на ринку, можна дізнатися, що пошук співпадінь відбувається за допомогою номерів порту (джерела та призначення одночасно) та номера пакету IP. У випадку TCP/IP номери послідовності можуть також бути взятими до уваги.

Це означає не зовсім сприятливі умови для програмного забезпечення тунелю ICMP, оскільки пакети цього протоколу не мають поля для номерів порта.

Однак, вони мають свій, внутрішній, номер послідовності в структурі пакету ICMP і реалізації NAT-шлюзів беруть його до уваги для пошуку співпадінь.

Експериментальні дослідження були проведені з використанням бездротового маршрутизатора LinkSys WRT54GSV4 (рис. 2.3), настроєного на трансляцію адрес з приватної мережі 10.0.0.0/24 до мережі Інтернет. Маршрутизатор було налаштовано так, що він виконував базову трансляцію адрес без будь-яких додаткових фільтрацій.

Рисунок 2.3. Маршрутизатор SOHO-класу LinkSys WRT54GSV4

Підтверджено, що реалізація NAT-шлюзу на маршрутизаторі LinkSys WRT54G2.3SV4 дійсно покладається на номер послідовності в пакеті ICMP для того, щоб знаходити відповідність «ехо-запитів» до «ехо-відповідей». Отже, спеціальні заходи для контролю за номерами послідовностей мають бути вжиті в програмному забезпеченні тунелювання ICMP.

Але це не є єдиною проблемою для ПЗ тунелювання. Більшість маршрутизаторів класу SOHO (домашній сектор та сектор малого офісу) мають досить обмежений об’єм пам’яті. Тому реалізації NAT розроблені таким чином, що записи в таблиці для пошуку відповідностей будуть видалені через певний час їх неактивності, працюючи схожим чином з FIFO-буферами.

На сьогоднішній день швидкість каналів зв’язку між провайдерами послуг Інтернет за допомогою високошвидкісної волоконно-оптичної технології дозволяє отримати відповідь на «ехо-запит» за лічені секунди, навіть якщо користувач під’єднаний до Інтернет через телефонний доступ.

Знаходячись позаду NAT, «ехо-запити» можуть досягти цільового вузла та спричинити відповідь досить швидко. Однак, якщо цей процес триває досить довго, маршрутизатор може не впізнати «ехо-відповідь», навіть якщо джерело все ще чекає на неї. Більше того, не існує гарантованого способу відправити «ехо-запит» з Інтернет на вузол, який знаходитьс позаду NAT.

Щоб запобігти цьому, ПЗ тунелювання ICMP має включати пакети «підтримки», коли серверна сторона періодично відправляє порожні пакети даних тільки для того, щоб існував відповідний запис в таблиці відповідностей шлюзу.

Коли потрібно, клієнтська сторона бере номер послідовності останнього отриманого номера та використовує його при подальших комунікаціях. Таким чином, маршрутизатор вважає зв’язок відновленим.

Приклад середовища, розробленого для тестування ідеї тунелювання ICMP, та типові отримані результати показано нижче. Для мінімізації кількості службового трафіку при невеликих швидкостях обміну тут використано алгоритм стискання ZLIB для внутрішнього вмісту пакету даних.

Рисунок 2.4. Microsoft NetworkMonitor показує активність ICMP тунелю (немає послання по тексту!)

Рисунок 2.5. Деталі інформації тунелю на серверній стороні (посилання!)

Рисунок 2.6. Інтерфейс користувача тестового середовища на клієнтському боці (посилання!)

При належних умовах цілком можливо встановити транспортний канал зв’язку, що не детектується звичайними способами, які не включають безпосередній аналіз інформації, що передається по мережі. Ні утиліта NETSTAT, ні більшість користувацьких файрволів на сьогоді не показує інформацію, яка відноситься до ICMP.

Потрібно особливо відзначити той факт, що оболонка командного рядка працює цілковито на не-транспортних протоколах.

Поиск по сайту: