Усе почалося зі звичайного експерименту зі штучним інтелектом. Я вирішив підключити Claude Code до свого домашнього роутера, щоб перевірити, наскільки корисним може бути AI-агент для керування мережею. Але під час перевірки безпеки виявив дещо несподіване: мій роутер досі намагався зв'язуватися із сервером інтернет-провайдера, послугами якого я не користувався вже три місяці.
Спочатку це виглядало як звичайні залишки старої конфігурації. Проте подальше дослідження показало, що за певних умов цей механізм дозволяє підмінити сервер керування роутером, змінити його налаштування й отримати можливість керувати ним віддалено. Причому для цього не потрібно підбирати пароль адміністратора або використовувати якусь складну програмну вразливість.
У цій статті я розповім, як працює ця технологія, що саме мені вдалося перевірити на власному обладнанні та чому звичайний домашній роутер може мати значно більше можливостей віддаленого керування, ніж здається на перший погляд.
Звичайний експеримент із Claude Code
Мій роутер — TP-Link WR845N v4. Я налаштував на ньому SSH-доступ, щоб Claude Code міг підключатися до пристрою та виконувати команди. Сам агент працював на моєму MacBook, тому встановлювати на роутер будь-які додаткові AI-моделі чи програми не довелося.
Ось тут треба виконати одну секретну командуПринцип доволі простий: я пишу агенту звичайною мовою, що потрібно зробити, а він сам визначає необхідні команди й виконує їх через SSH. Таким чином можна переглядати мережеву статистику, аналізувати конфігурацію, діагностувати проблеми або змінювати налаштування без постійного використання вебінтерфейсу роутера.
Спочатку я попросив Claude проаналізувати підключені пристрої. На основі доступної мережевої статистики агент спробував визначити, які пристрої зараз активні, якими застосунками можуть користуватися їхні власники й навіть у яких кімнатах вони приблизно перебувають. Останнє він оцінював за рівнем Wi-Fi-сигналу. Звісно, це були лише припущення, але деякі з них виявилися доволі точними.
Наступним експериментом стало керування налаштуваннями. Я перевірив, чи може агент виконувати звичайні адміністративні завдання, які раніше доводилося робити вручну. Це працювало, тому я вирішив піти далі й попросив Claude провести аудит безпеки роутера.
Приблизно за п'ять хвилин агент підготував звіт із шістнадцятьма потенційними проблемами. Серед них були досить звичайні речі: стандартне ім'я адміністратора, налаштування оновлення прошивки, некоректний системний час та інші недоліки конфігурації. Однак один пункт привернув особливу увагу. Виявилося, що мій роутер налаштований приблизно раз на добу звертатися до зовнішнього сервера, адреса якого належала моєму колишньому інтернет-провайдеру.
Роутер я не змінював, коли переходив до нового оператора. Але тоді мені й на думку не спадало, що в ньому може залишитися активний механізм віддаленого адміністрування, пов'язаний зі старим провайдером.
Як провайдери віддалено керують нашими роутерами
Щоб зрозуміти, що саме я знайшов, потрібно розібратися з технологією під назвою TR-069. Це протокол, який дозволяє інтернет-провайдерам віддалено налаштовувати й обслуговувати обладнання своїх абонентів. Він використовується для цілком практичних завдань: діагностики з'єднання, зміни мережевих параметрів, перезавантаження пристроїв, оновлення прошивок та інших адміністративних операцій.
Уявіть великого провайдера, який обслуговує десятки тисяч клієнтів. Якби для кожної зміни налаштувань потрібно було відправляти майстра до абонента, підтримка такого обладнання стала б надзвичайно дорогою та повільною. Саме тому існують системи централізованого керування. Провайдер може виконувати значну частину адміністративних завдань зі свого сервера, а роутери підтримують із ним зв'язок.
У TR-069 такий сервер називається ACS (Auto Configuration Server). У роутері зберігається його адреса, а також параметри, які визначають, коли потрібно виходити на зв'язок. Наприклад, пристрій може бути налаштований звертатися до сервера один раз на добу.
Найпростіше уявити це як розмову працівника з керівником. Щодня працівник телефонує за збереженим номером і запитує, чи є для нього нові завдання. Якщо завдань немає, він продовжує працювати як зазвичай. Якщо керівник хоче щось змінити, то передає відповідні інструкції.
Приблизно так працює й TR-069. Роутер сам встановлює з'єднання із сервером, повідомляє інформацію про себе та отримує відповідь. Якщо сервер має відповідні повноваження і пристрій підтримує необхідні функції, під час цієї сесії можна читати або змінювати параметри конфігурації.
Тут є важливий нюанс: саме роутер зазвичай першим звертається до сервера, а не сервер підключається до роутера. Тому для такого керування не обов'язково відкривати звичайну адміністративну панель в інтернет. Роутер сам створює вихідне з'єднання, отримує необхідні команди та завершує сеанс зв'язку.
І це цілком нормальна, корисна технологія. Але, як і з будь-яким іншим механізмом віддаленого керування, дуже важливо, щоб пристрій міг перевірити, кому саме він довіряє.
Що було не так із моїм роутером
Коли я детальніше дослідив налаштування TR-069, то звернув увагу на дві обставини. По-перше, адреса сервера залишилася від попереднього інтернет-провайдера. По-друге, вона починалася зі звичайного http://, а не https://.
Чому це важливо? HTTPS використовує TLS, який не лише шифрує дані під час передавання, а й дозволяє клієнту перевірити справжність сервера за його сертифікатом. Звичайний HTTP такого захисту не забезпечує. Це означає, що пристрій, який має можливість втрутитися в мережевий обмін, потенційно може прочитати або змінити його вміст.
Повернімося до прикладу з працівником і керівником. Уявімо, що працівник регулярно телефонує начальнику за певним номером, але не має надійного способу перевірити, хто саме відповів. Якщо стороння людина зможе перенаправити дзвінок на себе, працівник може вирішити, що спілкується зі своїм керівником, і почати виконувати чужі вказівки.
Приблизно такий ризик виникає, коли роутер не може достовірно перевірити сервер керування. Адже для пристрою важливо не те, якій компанії насправді належить сервер, а те, чи відповідає з'єднання закладеним у прошивку правилам довіри.
Звичайно, використання HTTP саме по собі ще не означає, що будь-який сервер автоматично зможе керувати роутером. Існують додаткові механізми автентифікації та обмеження, які можуть перешкодити такій атаці. Але перевірка конфігурації мого пристрою дала підстави припустити, що в конкретному випадку захисту може бути недостатньо.
Тому я вирішив перевірити це на практиці. Мене цікавило, чи зможе роутер прийняти сторонній сервер за справжній ACS і чи дозволить змінювати свої налаштування через нього.
Експеримент із Raspberry Pi та підставним сервером
Для перевірки я використав Raspberry Pi — невеликий одноплатний комп'ютер, який можна застосовувати для різноманітних мережевих експериментів. Я підключив його між своїм роутером та інтернетом так, щоб трафік проходив через цей проміжний пристрій.
У звичайній ситуації роутер звертався до адреси ACS старого провайдера. Моє завдання полягало в тому, щоб у контрольованій лабораторній мережі перенаправити це звернення на власний сервер. Для цього я використав механізм DNS, а роль сервера керування виконував GenieACS — програмне забезпечення для адміністрування пристроїв через TR-069.
Щоб зрозуміти принцип, достатньо згадати, як працює DNS. Коли пристрій звертається до сервера за доменним ім'ям, йому потрібно дізнатися відповідну IP-адресу. Для цього він надсилає DNS-запит, а отримана відповідь допомагає визначити, куди саме встановлювати з'єднання. DNS часто порівнюють із телефонною книгою інтернету: ви знаєте назву потрібного абонента, а система повідомляє його адресу.
Тепер уявімо, що хтось отримав можливість підмінити цю відповідь. Пристрій запитує адресу одного сервера, але отримує адресу зовсім іншого. Якщо подальше з'єднання не має належної перевірки справжності сервера, пристрій може почати спілкуватися не з тією системою, до якої спочатку збирався звернутися.
Саме цей принцип я використав у своєму експерименті. Raspberry Pi допоміг перенаправити звернення роутера до ACS на мій тестовий сервер. А GenieACS забезпечив підтримку самого протоколу TR-069, тобто міг приймати повідомлення пристрою та взаємодіяти з ним через стандартні механізми керування.
Під час перевірки роутер дійсно встановив з'єднання з моїм сервером. Я зміг отримати інформацію про пристрій та перевірити доступні можливості адміністрування. Це підтвердило, що в досліджуваній конфігурації роутер прийняв підставний ACS.
Але на цьому я вирішив не зупинятися. Мене цікавило значно важливіше питання: чи можна зробити так, щоб після завершення підміни роутер продовжив самостійно звертатися до мого сервера, навіть якщо Raspberry Pi більше не буде підключений?
Як тимчасова підміна перетворилася на віддалене керування
Виявилося, що TR-069 передбачає можливість змінювати адресу самого сервера керування. Ця адреса є одним із параметрів конфігурації, і певні реалізації протоколу дозволяють змінювати її через ACS.
Повернімося до прикладу з працівником і начальником. Уявіть, що працівник зателефонував за звичним номером, але через перенаправлення слухавку взяла стороння людина. Вона не просто передала йому завдання, а повідомила, що відтепер керівник працює за новим номером. Працівник зберіг цей номер і надалі почав телефонувати вже за ним.
Приблизно це й відбулося з моїм роутером. Через тестовий ACS я змінив адресу сервера керування на адресу власного віддаленого VPS. Роутер прийняв нові параметри та зберіг їх у своїй конфігурації.
Після цього я відключив Raspberry Pi й повернув звичайне підключення до інтернету. Початкова підміна більше не працювала, але виявилося, що вона вже й не потрібна. Роутер продовжував самостійно звертатися до нового сервера, адресу якого отримав під час експерименту.
Це стало найважливішим результатом усього дослідження. Тимчасової можливості втрутитися в мережевий зв'язок вистачило, щоб змінити постійні налаштування сервера керування. Надалі роутер сам встановлював з'єднання з моїм ACS через інтернет, без участі Raspberry Pi.
При цьому мені не потрібно було відкривати вебінтерфейс роутера для зовнішніх підключень або налаштовувати переадресацію портів. TR-069 уже мав механізм, через який пристрій сам виходив на зв'язок. Я лише продемонстрував, що за недостатньої перевірки сервера цей механізм можна переналаштувати на іншу адресу.
Що можна робити з роутером через TR-069
Після успішного експерименту виникає логічне питання: які можливості отримує той, хто контролює ACS?
Насправді все залежить від конкретного пристрою та його прошивки. TR-069 передбачає широкий набір операцій для адміністрування обладнання, але це не означає, що кожен роутер підтримує абсолютно всі з них. Виробники самостійно визначають, які параметри будуть доступні, а які залишаться обмеженими.
На своєму TP-Link я зміг отримати інформацію про підключені пристрої, а також перевірити можливості керування мережевими налаштуваннями. Зокрема, під час дослідження вдалося отримати пароль Wi-Fi та дані для підключення до інтернету.
Залежно від реалізації через ACS також можна змінювати назву та пароль бездротової мережі, переналаштовувати DNS, перезавантажувати пристрій, виконувати діагностику або ініціювати оновлення прошивки. Деякі з цих можливостей на перший погляд здаються нешкідливими, але в чужих руках вони можуть створювати суттєві ризики.
Наприклад, DNS відповідає за перетворення доменних імен на IP-адреси. Коли ви відкриваєте сайт, пристрій зазвичай використовує DNS, щоб дізнатися, за якою адресою розташований потрібний сервер. Якщо хтось отримує можливість змінити DNS-налаштування роутера, він потенційно може впливати на те, як пристрої домашньої мережі знаходять інтернет-ресурси. Це не означає, що така людина автоматично зможе читати захищений HTTPS-трафік, але ризики перенаправлення й маніпуляцій із мережевими з'єднаннями все одно залишаються.
Ще одна важлива деталь полягає в тому, що власник роутера може навіть не помітити змін. TR-069 призначений для автоматизованого адміністрування, тому виконання команд не обов'язково супроводжується повідомленнями на телефоні або попередженнями у звичайному інтерфейсі користувача.
Чи може таке статися з будь-яким роутером?
Тут важливо правильно розуміти межі експерименту. Я досліджував власне обладнання в контрольованих умовах і мав можливість фізично втрутитися в мережеве з'єднання. Саме це дозволило організувати початкове перенаправлення трафіку.
Тому неправильно стверджувати, що будь-який роутер із TR-069 можна зламати просто через інтернет. Для повторення подібного сценарію сторонній людині спочатку потрібно отримати можливість впливати на з'єднання між пристроєм та сервером керування. Також необхідно, щоб реалізація TR-069 не мала достатнього захисту від підміни сервера.
З іншого боку, фізичне підключення обладнання до кабелю — лише один із можливих сценаріїв отримання контролю над мережевим шляхом. Ризик може виникнути й за інших обставин, якщо стороння особа отримала можливість змінювати маршрутизацію, DNS-відповіді або трафік у відповідній мережі.
Саме тому безпека таких протоколів не повинна залежати лише від припущення, що до мережі ніхто сторонній не дістанеться. Правильно налаштований механізм керування має перевіряти, з яким сервером спілкується пристрій, навіть якщо хтось намагається перенаправити його з'єднання.
У випадку HTTPS це забезпечується, зокрема, перевіркою TLS-сертифіката сервера. Якщо роутер очікує з'єднання з конкретним ACS, підставний сервер без належного сертифіката не повинен пройти таку перевірку. У поєднанні з іншими засобами автентифікації це значно зменшує ризик подібних атак.
Хто відповідає за безпеку такого механізму?
Після цього експерименту в мене виникло ще одне питання: чому подібна ситуація взагалі стала можливою?
З одного боку, виробник роутера відповідає за реалізацію протоколу, перевірку справжності сервера, захист конфіденційних параметрів і загальну безпеку прошивки. З іншого — інтернет-провайдер, який використовує TR-069 для керування обладнанням, повинен належним чином конфігурувати цю систему та захищати інфраструктуру адміністрування.
Але є й третя сторона — власник обладнання. Якщо роутер залишається у користувача після зміни провайдера, стара конфігурація не обов'язково зникає автоматично. Саме так сталося в моєму випадку. Я змінив оператора, продовжив користуватися пристроєм і не підозрював, що він досі має налаштування віддаленого керування, пов'язані з попередньою мережею.
Водночас залишена адреса ACS сама по собі не доводить, що колишній провайдер продовжував керувати моїм обладнанням. Для цього потрібні були б додаткові докази фактичних з'єднань і виконаних команд. У моєму дослідженні головним результатом стала не поведінка старого провайдера, а можливість підмінити сервер керування в конкретній конфігурації роутера.
Якщо ви користуєтеся власним маршрутизатором, особливо після зміни інтернет-провайдера, варто перевірити налаштування віддаленого адміністрування. У вебінтерфейсі вони можуть називатися TR-069, CWMP або ACS. Якщо функція не використовується й не потрібна для роботи вашого підключення, її можна вимкнути. Водночас на обладнанні, яке належить або адмініструється провайдером, краще спочатку уточнити, чи не потрібна вона для підтримки послуги.
Також важливо регулярно оновлювати прошивку. А якщо роутер раніше використовувався з іншим провайдером, варто перевірити, чи не залишилися там старі параметри, облікові записи або адреси серверів керування.
Яку роль у цій історії відіграв штучний інтелект?
Напевно, найбільше мене вразило те, що спочатку я взагалі не планував досліджувати TR-069. Я просто хотів перевірити, чи зможе Claude Code адмініструвати домашній роутер й наскільки зручним буде такий спосіб взаємодії з мережевим обладнанням.
У результаті агент не лише допоміг мені дослідити конфігурацію, а й звернув увагу на параметр, який я сам, найімовірніше, навіть не помітив би. Далі звичайний аудит перетворився на окреме дослідження протоколу, роботи DNS і механізмів віддаленого керування.
Щоправда, коли я перейшов від аналізу до практичної перевірки можливості підміни сервера, Claude Code відмовився допомагати з деякими діями. Попри те, що експеримент проводився на моєму власному обладнанні, запити стосувалися технік, які можуть використовуватися для несанкціонованого доступу. Це стало ще однією цікавою частиною дослідження: агент допоміг виявити проблему, але мав обмеження щодо подальшої практичної перевірки.
І все ж я не вважаю, що Claude якимось магічним способом «зламав» роутер. Він став інструментом, який допоміг швидше розібратися в незнайомій технології, проаналізувати конфігурацію та сформулювати припущення для перевірки. Сам експеримент спирався на звичайні мережеві механізми, які існували задовго до появи сучасних AI-агентів.
Для мене саме в цьому й полягає одна з найцікавіших можливостей штучного інтелекту: він дозволяє досліджувати складні технічні системи, навіть якщо спочатку ти не маєш глибоких знань про всі їхні компоненти. Звісно, результати роботи агента потрібно перевіряти, а остаточні висновки робити на основі реальної поведінки системи.
Висновок
У результаті звичайний експеримент із Claude Code перетворився на дослідження механізму віддаленого керування домашнім роутером. Я виявив застарілу конфігурацію TR-069, перевірив можливість підміни ACS у власній лабораторній мережі та продемонстрував, що після зміни адреси сервера пристрій продовжував самостійно звертатися до нового ACS навіть без Raspberry Pi.
Найцікавіше, що для цього не знадобилося ламати прошивку, підбирати адміністративний пароль або встановлювати стороннє програмне забезпечення на сам роутер. Усе відбувалося через штатний механізм, призначений для легального віддаленого адміністрування.
Проблема полягала не в самому існуванні TR-069, а в тому, що в конкретній конфігурації роутер прийняв підставний сервер керування за довірений і дозволив змінити відповідні параметри. Тимчасове втручання в мережеве з'єднання таким чином перетворилося на можливість подальшого віддаленого керування.
Після завершення експерименту я прибрав тестові налаштування та вимкнув непотрібне віддалене адміністрування.
Ця історія ще раз нагадала мені, що ми далеко не завжди знаємо, як насправді працюють пристрої, якими користуємося щодня. Домашній роутер здається простим пристроєм, що роздає інтернет, але за його звичайним вебінтерфейсом можуть приховуватися складні системи керування, діагностики й автоматизації.
Іноді достатньо одного правильно поставленого запитання, щоб відкрити цілий пласт технологій, про існування яких раніше навіть не замислювався.