UPNP інтерпретується так: Для приватного комп'ютера функція UPnP від BitComet може змусити модуль NAT шлюзу або маршрутизатора автоматично відображати порти, які BitComet слухає, від шлюзу або маршрутизатора до внутрішньомережевого комп'ютера.
Модуль мережевого фаєрвола шлюзу або маршрутизатора починає відкривати цей порт для інших комп'ютерів в Інтернеті.
Технологія обходу NAT дозволяє веб-додаткам визначати, чи знаходяться вони за NAT-пристроєм з підтримкою UPnP. Ці програми отримують спільну глобальну маршрутизовану IP-адресу та налаштовують відображення портів для пересилання пакетів із зовнішніх портів NAT до внутрішніх портів, які використовує додаток — усе це автоматично, без необхідності користувачам вручну відображувати порти чи робити щось інше. Технологія обходу NAT дозволяє мережевим пристроям або одноранговим додаткам спілкуватися із зовнішнім світом через шлюзи NAT, динамічно відкриваючи та закриваючи порти зв'язку з зовнішніми сервісами.
Іншими словами, це можна підсумувати так: ефективність конвертації простого NAT не є високою, і якщо буде запущена технологія UPNP, ефективність конвертації даних NAT може бути підвищена.
Звучить як добре. Але що ???
UPNP має серйозні недоліки: ось уривок:
Перший недолік полягає в тому, що використання буферів не контролюється і не обмежене. Зовнішні зловмисники можуть отримати права контролю над усією системою завдяки цьому! Оскільки функція UPnp має використовувати порти комп'ютера для роботи, зловмисник, який отримує контроль, також може використовувати ці порти для досягнення мети зловмисника. Наслідки цього дефекту дуже серйозні, незалежно від версії системи Windows, поки UPnP працює, існує така небезпека! Але строго кажучи, це не зовсім проблема самої технології UPnP, а радше програмний недогляд.
Другий недолік пов'язаний із робочим механізмом UPnP. Дефект існує на етапі «виявлення пристрою», коли працює UPnP. Виявлення пристрою можна поділити на дві ситуації: якщо комп'ютер з підтримкою UPnP успішно завантажується і підключається до мережі, він негайно надсилає «трансляцію» в мережу, повідомляючи UPnP-пристрій про готовність, а на програмному рівні трансляційний контент є інструкцією M-SEARCH (повідомлення). Трансляція буде «почута» всіма пристроями в межах «звукової досяжності». І надсилає релевантну інформацію комп'ютеру для подальшого керування.
Аналогічно, якщо пристрій просто підключений до мережі, він також надсилатиме «сповіщення» мережі про готовність прийняти керування з мережі, що є індикацією NOTIFY на рівні програмування. Він також приймається всіма комп'ютерами в діапазоні «звукового діапазону». Комп'ютер «відчує», що пристрій «доповів самому собі». Насправді інструкції NOTIFY надсилаються не лише комп'ютерам, а й можуть бути почуті іншими мережевими пристроями. Саме у згаданій вище трансляції та прослуховуванні виникає проблема!
Якщо хакер надсилає інструкцію NOTIFY на систему користувача, система користувача отримає цю інструкцію NOTIFY і підключається до конкретного сервера за її інструкціями, а потім запитує сервіс завантаження на відповідний сервер — завантажує вміст сервісу для виконання. Сервер, звісно, відповість на цей запит. Сервісна система UPnP пояснить опис пристрою, запитує надсилання додаткових файлів, і сервер повинен буде відповідати на ці запити. Таким чином утворюється цикл «запит-відповідь», який займає велику кількість системних ресурсів і змушує швидкість обслуговування UPnP уповільнюватися або навіть зупинятися. Отже, цей недолік зробить можливим атаку «відмова в обслуговуванні»!
Інакше кажучи, функція UPNP постійно споживає власні мережеві ресурси під час етапу використання, і коли мережеві ресурси пристрою вичерпаються, виникає явище призупиненої анімації. Просто подивіться на наведену вище інформацію. |
Опубліковано 12.10.2017 08:58:01
|
|
|
|
