UPNP се тълкува по следния начин: За частен компютър функцията UPnP на BitComet може да накара NAT модула на шлюза или рутера да извършва автоматично картографиране на портове и да картографира порта, който BitComet слуша, от шлюза или рутера към интранет компютъра.
Мрежовият защитна стена на шлюза или рутера започва да отваря този порт към други компютри в интернет.
Технологията за преминаване на NAT позволява на уеб приложенията да откриват дали се намират зад устройство с UPnP, способно за NAT. Тези програми след това получават споделен глобален маршрутизираем IP адрес и конфигурират картографирането на портове, за да пренасочват пакети от външни NAT портове към вътрешните, използвани от приложението – всичко това автоматично, без нужда потребителите ръчно да картографират портове или да правят нещо друго. Технологията за преминаване на NAT позволява на мрежови устройства или peer-to-peer приложения да комуникират с външния свят чрез NAT шлюзове чрез динамично отваряне и затваряне на комуникационни портове с външни услуги.
С други думи, може да се обобщи така: ефективността на преобразуване на прост NAT не е висока, и ако се пусне UPNP технологията, ефективността на конверсията на NAT данни може да се подобри.
Звучи като нещо добро. Но какво???
UPNP има сериозни недостатъци: Ето откъс:
Първият недостатък е, че използването на буфери не е контролирано и ограничено. Външни нападатели могат да получат контролни права върху цялата система чрез това! Тъй като функцията UPnp трябва да използва портовете на компютъра, нападател, който получи контрол, може също да използва тези портове, за да постигне целта на нападателя. Последиците от този дефект са много сериозни, независимо от версията на Windows системата, докато UPnP работи, съществува тази опасност! Но строго погледнато, това не е изцяло проблем с самата UPnP технология, а по-скоро програмен пропуск.
Вторият недостатък е свързан с работния механизъм на UPnP. Дефектът съществува във фазата "откриване на устройство", когато UPnP работи. Откриването на устройство може да се раздели на две ситуации: ако компютър, поддържащ UPnP, стартира успешно и се свърже към мрежата, той незабавно ще изпрати "излъчване" към мрежата, уведомявайки UPnP устройството в мрежата, че е готово, а на програмно ниво излъчваното съдържание е M-SEARCH (съобщение) инструкция. Излъчването ще бъде "чуто" от всички устройства в рамките на "звуковия обхват". И да обратна връзка с релевантната информация към компютъра за последващо управление.
По същия начин, ако устройство е просто свързано към мрежата, то също ще изпрати "известие" към мрежата, че е готово да приеме контрол от мрежата, което е индикация NOTIFY на програмно ниво. Той ще бъде приет и от всички компютри в диапазона "звуков обхват". Компютърът ще "усети", че устройството е "докладвало на себе си". Всъщност инструкциите NOTIFY не само се изпращат към компютрите, но могат да бъдат чути и от други мрежови устройства. В гореспоменатото предаване и слушане има проблем!
Ако хакер изпрати инструкция NOTIFY към системата на потребителя, системата на потребителя ще получи тази инструкция и ще се свърже с конкретен сървър под неговите инструкции, след което ще поиска услуга за изтегляне към съответния сървър – изтегли съдържанието на услугата, която трябва да бъде изпълнена. Сървърът, разбира се, ще отговори на тази молба. Системата за обслужване на UPnP ще обясни описанието на устройството, като ще поиска изпращане на още файлове, а сървърът ще трябва да отговори на тези заявки. По този начин се формира цикъл "заявка-отговор", който заема голямо количество системни ресурси и кара скоростта на обслужването на UPnP системата да се забави или дори да спре. Така че този недостатък ще направи възможна атака "отказ на обслужване"!
Всъщност, с други думи, функцията UPNP постоянно изразходва собствените си мрежови ресурси по време на етапа на използване, и когато мрежовите ресурси на устройството се изчерпят, възниква явление на суспендирана анимация. Просто погледнете горната информация. |
Публикувано в 12.10.2017 г. 8:58:01 ч.
|
|
|
|
